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Description 

Field ol the Inveniion 

s This invention relates to computer numeric controlled (CNC) machine tools and ,n particular, to the control systems 

used to operate such machine tools. 

Background of the Invention 

,o CNC Control Systems The purpose of a CNC machine is to use a set of input specifications describing a physical 

obiect to produce a machined part according to the specifications. The part is typically formed from solid block stock 
material such as metal, and shaped by various machine tools such as drills, mills, lathes, electrostatic discharge ma- 
chines (EDMs) gauging systems and the like. CNC machines are complex and include hundreds of components. 
Examo les of inpul devices include keyboards, operator consoles, pressure sensitive CRTs, various tools and machine 
»s sensors limit switches and network interfaces. Output devices include motion controllers that send motion control 
s r g na°s to motors drrving axes or a tool. CRT dispfcys, console status lights and audiblaalarms. Other components 
indude microprocessors memory, disk drives, data buses and wiring harnesses. The software executed by the com- 
pute ^processons a critical component of a CNC machine, as it coordinates the functions of the al. the other components 
1 of the system In general. CNC software is custom written for the particular brand of components a CNC manufacturer 
- o svs'em tnTegrator chooses to include in the CNC machine. As a result. CNC software .s extremely complex, and a 
" S^pSJrSln* for a particular CNC machine must be intimately familiar with the way virtually every hardware 
comDonent interfaces with the software, and with the entire software system itself. 

For example, two representative functions of most CNC software are the logic and mot.on contro. funct.ons col- 
lectively referred to herein as the -kernel-). The logic control function keeps track of the spec, f.c sequence of steps 
2 s ma mus be taken by various movable hardware components to accomplish a task. For example, the steps required 
to^ a^aLdy sized drill bit into the too. holder of a spindle from an automatic tool changer in a m hng apple. t.on 
SS f) send a command to raise the spindle containing the currently mounted drill bit so the too. changer «nU frt 
uXneath , (2 ) send a command to the tool changer instructing it to move below the spindle, (3) send a command 
to fhe sp^dleins ructing it to release the currently mounted drill bit. (4) wait for a signal from the sp.ndle md.catmg th* 
30 he dru. 5 has been released, (5) send a command to the tool changer instructing it to move to rotate clockwise 30 
dea^ees to porton the new drill bit below the spindle. (6) interrogate the too. changer to confirm that the too. changer 
has success^ly executed the rotation command. (7) send a command to the spind.e command.ng ,t to engage the 
new Z b t nde neath ,t in the too, changer, and (8) send a command to the too. changer instructing -t move away 
from the spind.e and work area. Given the hundreds of moving, controllable parts m a CNC machine tool, the log.c 
3S control function is much more complex than the above simplified example illustrates. 

The rSon control function of the software receives commands describing how a particular ax.s or motor should 
be moverFo°exam P ,e. -n the above examp.e for logic control, the logic control function sent the 
) a command tc- -aise L spin Jie. The motion control function takes this -general' command, breads rt down into smaMer 
J disc^S movement- =: * controMably move the spind.e up 0 00T at a time until it has mo. ed -p a tote' cf * .nches) 
/ and senS revive elects signals from precision motors to ensure the movement is ca.ed out. The r^on control 
: ! a*o able to execute more complex, multidimensional commands, such as to move tne axes o, a mH.-na 
machine in a pattern so as to cut an ellipse of specified dimensions in a workp.ece. 

Because the mot.on control function is the portion o, the software (except for device drivers) that mteracts most 
clos^h thThardware components that actually carry out shaping processes on a workp.ece. the mot.on control 
2 a L^ecetes ^formation about hardware faults from hardware devces. For examp.e. if a hardware devce s 
unabTt f^a^inatrucwi. the motion contro. function will recerve a notice of the error from the hardware (or .ts 
%^J^£S£r) Th.s information needs to be communicated back to the other portion of the CNC control 
softwa^resZs!bte for requesting the motion contro. funct.on to comp.ete the funct.on the software is currently on- 
T™*°r^*££pnL action, such as displaying a message on the operator CRT. may occur 
a?e usuaVmany other port.ons of the CNC contro. system software that w... a.so need to be ■nformed of the hardware 

srss rrr^r r rsiE. - — burden on , e ^ ^ 0 , 

CNC contro, system ^5^:^^ ^- software system us.ng structured 
,echnZs U :nar a r.Te ^ ™* * ' ^-position). Th- .has resuftec , * 

techn ques mat anaryze wnat example, software code relating to the user .ntertace by wh.ch a 

zs^T^zzz^*™ * « ■»«- * - cnc sys,em such as ,he 
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motion controller. One example is that wWn a motion controller receives a signal from a mffnine tool indicating a fault 
condition (for example, when an object in the work area prevents the table from moving to a desired location, or a 
blown fuse), the motion controller might directly display an error message on the CRT display Because prior CNC 
control system software generally is not broken down into portions corresponding to the discrete, physical components 

5 of a CNC machine tool, a change in one portion of the software is difficult to make and frequently requires changes to 
other portions of the software. 

Another example illustrating this problem occurs when a user, system integrator or even machine tool manufacturer 
wishes to add a new hardware component to the machine tool. For example, it may be desirable to replace an AC 
induction motor with a DC brushless motor from a different manufacturer. The new motor will likely use a different 

to communications protocol and have different tolerance specifications and operating limits. Therefore, the motion control 
software will need to be modified to be able to communicate with the new motor using its communications protocol. 
The user interface will also need to be modified so that the user may specify the improved tolerance parameters. 
However, with past CNC software, these changes will have a ripple effect throughout the entire software system, greatry 
increasing the time required to develop a new software system capable of using the new motor. Many of the additional 

is revisions are caused by the fact that the data the software needs to access is dispersed throughout the entire software 
system. For example, to add a new software function, the software may need to know, what tool is presently in the 
spindle, the speed the spindle is rotating, the coordinates of the axes (location of the table), the readings of a thermal 
sensor, information about forces being exerted on the cutting spindle, and the stage (or step) of processing the work- 
piece is currently in. In past CNC systems, this information would likely be diffused throughout various software mod* 

20 ules, and the way these data elements interact is either too complex to discern (except to the original software author), 
^ or proprietary. 

These problems with CNC control systems have led to several other problems throughout the industry. There is a 
long lead time for system integrators or CNC machine tool manufacturers to be able to incorporate new hardware 
components into existing systems. This problem applies not only to new CNC machine designs, but also to efforts to 

2$ add improved or additional components to an existing CNC machine tool, or to retrofit an existing machine tool with 
CNC capabilities. Another problem is that of scalability. Because CNC control software is usually written for use in 
accordance with an anticipated collection of hardware components, the same software can not be easily adapted for 
use in connection with other hardware components. In other words, CNC software is generally not "scalable," meaning 
that the software used to operate sophisticated, high-end CNC machines can not also be used to operate 'bare-bones, 

30 • low-end CNC machine tools. As a result, CNC manufacturers 'reinvent' software having the same functionality merely 
because it designed to work in a CNC having different hardware components. 

Programmers for CNC control systems can also be required to "reinvent' software components not just in response 
to new hardware, but also in response to new standards for inputting descriptions of parts to be formed by the CNC 
machine. The earliest CNC machines accepted part definitions through punched paper tape. Subsequent CNC ma- 

35 chines (such as that disclosed in U.S. patent no. 4,477,754) interrogated a machine operator through a series of ques- 
tions to obtain instructions about how to create a desired part. More recently, several standard data file formats have 
emerged for describing parts to be machined, such as the HURCO conversational or RS-274D M&G code programs. 
In the past "part program interpreter' modules of CNC control system programs, each module used for accepting a 
part definition i.; a different format, would generally have to access, as described above, various data elements and 
} 4n software routines diffused throughout the CNC control system software. Again, each different input fnrrrvif has resulted 
J in a unique part program interpreter software program, and these programs all inciude much common and therefore 

rieediessly duplicative, functionality 

Obiec: C-isi-.eo Software Most existing programming languages provide "sequential" instructions for » processor 
to implement. These languages have previously been used to implement CNC control systems. However, computers 

*5 are often utilized for modeling systems of interactive components in order to determine sequences of actions such 
systems would perform under various conditions. For example, a programmer may wish to program a computer to 
mimic the manner in which some particular digital logic network responds to a particular input stimulus. When the 
programmer doesn't know beforehand what sequence of steps the logic network would carry out in response to the 
stimulus, but only knows how each individual component changes its outputs in response to a change to its inputs, the 

so programmer often finds it difficult to utilize sequentially organized instructions to program a computer to model the 
behavior of the system. 

In contrast to sequentially organized software, "object-oriented" software is organized into 'objects', each com- 
prising a block of computer instructions describing various procedures ("methods') to be performed in response to 
•messages" sent to the object. Such operations include, for example, the manipulation of variables and the transmission 
55 of one or more messages to other objects. Messages are sent and received between objects having certain functions 
and knowledge to carry out processes. When one of the objects receives a message, the object carries out an operation 
(a message procedure) corresponding to the message and. if necessary, returns a result of the operation. Each object 
has a region where internal states (instance variables) of the object itself are stored and where the other objects are 
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not allowed to access The objects compr.se concept objects that represent concepts and instance objects that rep- 
not allowed to access, i ne ooieci * concepts are clearly separated Irom the instances. One feature of the 
resent instances of the concept ob.ec as . Thj ^ conc ^ s ^ e ^cep^ecl there is defined an upper concept object 
object-onented system ,s '" h «^^ object, and the certain object can inherit 

that has a concept more abstract ^^^^^^ variab , e s) of the upper concept object to utilize them, 
the .unction, from £ upper concept object "shape' 

° f ZZ^^ -X^ i a^-oriented programming language by writing individual blocks of code each 
P r °9ra™ mer p '°»'° Hefinino ... meth ods A collection of such objects adapted to communicate with one 
°' t'Tbrmtans^fmes^ P-oQ«m. Object-oriented computer programming facil- 
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tool by an object oriented software program and relatively easy modification 
Objects of the Invention 

On e obiec,o,^i n »en,»n iS .op,=v« te ,CNC™ch i ne,oolconuo,sy 5 ,. m , na . U « 2 . S anob, e c,o,«ed P ^ 

" ^%^^™:Zl^C ™e h in. ,oo, con, ro , S ys,e m «. * scalable sucb «, . ™ y 

be used for either high end or low end CNC machine tools. 
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Another object of the invention is to provide a CNC machine tool control that is easily modifiable, in which previously 
written software can be reused, and in which new objects can be added which inherit or comprise compositions of 
previously defined objects. 

Another object of the invention is to provide a CNC machine tool control system in which new processes may be 
5 added by a programmer without requiring the programmer to know details of how particular hardware components 
carry out specific workpiece shaping processes. 

Brief Description of the Drawings 

l0 pjg 1 is a schematic diagram of the hardware components of a CNC machine tool system on which the control 

system of the present invention may operate. 

Fig. 2 is a schematic diagram of the types of software classes included in a CNC control system, and several 
representative types of object-oriented objects within several of these classes. 

75 Summary of the Invention 

The control system of the present invention provides a real-time CNC software system that isolates system re- 
sponsibilities into classes that permit a CNC manufacturer or system integrator to manage complexity and change. 
The control system allows different systems to be created from the same model and future, as yet unimagined, tech- 
^ 20 nological advances can be incorporated without redesigning or making massive changes. 

/ The system utilizes an object-oriented software environment.- A first class of object types is provided for processes 

(such as drilling, reaming, milling) to be carried out by machine tool components (the Process Class). Some processes 
objects may inherit characteristics of other objects in the Process class. For example, a •hole' object may have char- 
acteristics such as a depth and diameter, which can be inherited by other process objects, such as a drill, ream or bore 

25 process object. A second class of object types of is provided which represent instances of machine tool components, 
such as a table (axes), a spindle, tool changer or operator console. Again, some objects may inherit attributes of other 
objects. For example, an axis group, namely an object for simultaneously controlling multiple axes to shape complex 
three-dimensional objects, may be inherit attributes of a single axis object. Other objects may be composite objects of 
other tool objects. For example a tool changer may be a composite object of a collection of different milling bits which 

30 may be held in the tool changer (in addition to having its own attributes). 

Most importantly, during execution of the software component of the control system, the objects transmit messages 
to each other. For example a drill process object can be defined to hold all the information needed to define a drilling 
process, and this information may be sent in a message to an Machine Class spindle object (to move the spindle down 
and form the hole) and to an axis group object (to position the workpiece in the proper location). However, the portion 

35 of the software which defines the drilling process does not need to access information regarding how the actual machine 
tool component carries out its task, or how the motion control module controls the machine components. Therefore, 
in a software implementation, the same process object can be used in virtually any CNC machine, without undue regard 
to its manufacturer or specific hardware components. Moreover, the object oriented messages through which various 
objects communicate provide a standard interface for adding additional functional^ to a CNC machine tool control 
y system. 

For example, the primary purpose of a user interface is to collect information about a series of machining processes 
to oe performed. Once the basic infoimation is collected, the user interface can execute the processes by: (1) calling 
a process object with data about a new process to thereby create the object; (2) repeat step (1 ) for each process; an J 
(3) sequentially sending a message to each defined object telling it to execute itself. Thus, the programmer of the user 
interface may be completely insulated from motion control data required for the machine tools to carry out their tasks. 

Because communication between software objects is accomplished through messages, software functions can be 
more easily distributed among different, simultaneously executing tasks. For example, instead of a motion control 
module needing to keep track of which task needs information regarding a particular hardware fault, information re- 
garding a fault may merely be sent to an exception handler object. This allows the motion control module to devote 
so more processing time to its primary task of controlling motion, and permits all error conditions to be handled in a uniform 
manner Specifically, the exception handler may keep a database of which objects have a need to know about which 
types of faults, and report specific faults only to those objects. Therefore, in adding a new process or machine com- 
ponent object to the system, modification of the motion control module can be kept to a minimum as fault conditions 
may be handled by the exception handler. 
55 There are seven basic Classes of software components: Device Drivers. Operating System. Platform Services, 

the Kernel. Machine Class objects. Process Class objects, and the Operator Class. The Device Drivers class contains 
th interfaces to particular hardware such as the hard drive, floppy drive, serial and parallel ports, motion board, and 
I/O device. This isolates all hardware interfaces into a single class that only needs to be changed when new hardware 
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components are added to the existing system components and need to communicate in a different manner with the 
system. 

The Operating System class is responsible for hardware and software resource management. It manages memory, 
timers and the scheduling of all processesand tasks. This class makes it possible to port a control system in accordance 
with the present invention system toother hardware platforms. The Platform Services class is responsible for facilitating 
the execution of tasks such as error handling and communication between pari program interpreters and the lower 
levels of the system. This class simplifies system communications and only requires change if advances in computer 
science technology need to be incorporated because they improve the efficiency or change the management of initial- 
ization and message handling. The Kernel class handles continuous motion and discrete input/output implementation 
w components This class forms the stable core of the CNC control system that only needs to be changed when per- 
formance scaling is required. This approach is in sharp contrast to prior CNC control systems that require system 
developers to change the Kernel when making changes to the Operator Class objects, such as the Part Program 
Interpreter. 

The remaining three classes (Machine. Process, and Operator) specifically tailor any system to be a machine tool 
75 CNC The Operator and Process classes are the tools" used to communicate clearly to the above hardware-oriented 
classes. The Machine class contains the objects that makes this communication understandable by the Kernel com- 
ponents. 

The Machine class is a collection of objects that embody the abstraction of real-world components such as the 
> tool changer, spindle, or coolant. This class describes all generic categories of machine tool devices by their basic 
> required characteristics. Operator programs usually communicate through the objects in this class to the Kernel. The 
Machine class turns operator commands such as "change to tool #6* into a message or series of messages that can 
be understood by the Kernel's components. New machine tool components can be added to the Machine class and 
existing components can be easily modified without making changes to the Kernel. 

The Process class holds the Process techniques (methods) that perform specific common practices on the specific 
25 type of machine (low-end milling machine, lathe, punch press, EDM, gauging system, etc.). The objects in this class 
use multiple Machine Class objects and can be accessed from multiple part program interpreter (operator) programs. 
This class usually contains libraries of canned cycles to handle such operations as milling frames, tapping, and boring, 
but it also contains any subroutine that several different applications need to use. The objects provide easy accessibility 
to the complex CNC features. _ . 

so The Operator Class (including the Part Program Interpreter) is an extension of the CNC operator s skills and job 

functions It also holds the operator programs such as part programming and system diagnostics. This class makes 
use of services provided by other classes to manage control of the machinery. Using programs at this level, the operator 
can set the system parameters (e.g.. maximum feedrate) and communicate with the machine tool while it .s running a 
part program Most of the changes made to a CNC will be modifications to change what the operator can do. These 
35 changes usually affect the part programming and part cutting environment and can be made at this level with any 
accompanying techniques changed in the Process class. 

Engineers changing a control system of the present invention can easily make changes to the system because 
A they do ,iot --jed to be experts on the entire system to make a modification to a single component in a class. One 
) -har -j- does -tot have a ripple effect of change throughout the system. Portions of the system that are most iikefy to 
So change such as the user interlace and device drivers are separated from the Kernel. These components are mors 
accessible to change through PLC programs, customizations to the Machine ciass and addition to or modification of 
operator programs. 

Users of the control system of the present invention will have a more stable design that can be tested for com- 
pleteness The system makes possible the efficient reuse of system analysis, requirements, design, and components. 
45 The system forces system designers to consider all nearly all levels of CNC responsibilities to be handled by ob)ect- 
oriented software. In addition, changes at the Device Driver and Operating System levels may incorporate new tech- 
noloqies and at the Operator and Process levels will be changed to enhance or scale down system features and 
functionality. The core classes. Machine and Kernel, will change infrequently due to the 'all purpose 1 nature of the 
objects in these two classes. 

so The present system uses an open systems, object^riented design approach. Th,s allows users to tailor hardware 

and software to gain the competitive edge The CNC control system allows easy integration of hardware and software 
from different suppliers and permits the porting of systems to other hardware platforms. Industry standard hardware 
interfaces to simplify assembly and maintenance may be used. The system is dynamically reconf.gurable to easily 
permit third party development of software components. The system uses simple, standard messages in a message 

55 schema The messages are flexible and allow a user to select messages they want to use and to alter the messages 
to meet their needs. The system software is scalable to support less expensive and/or a full-featured CNC hardware 
system using the same software structure .. . 

As with data characteristics, services can also be inherited from the parent class when a new class or obiect is 
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created Ot course, the new class or objec^y use the service or create a different version^. DiHerent objects can 
use identical services Therefore, a software engineer writes the code for the service only once and then reuses it after 
that. The reusability of existing object-oriented code makes development and modification faster because there is less 
to write and maintain. 

A diagram of the system of classes of software component classes is shown in Fig. 2. 

The software objects use messages to communicate between the components. The class structure simplifies 
system operations and programming by limiting the messages of interest to each class. For example, the Mach.n 
class does not worry about the Kemers responsibilities such as travel limits and servo errors. Conversely, the Kernel 
is not concerned about ownership or devices because the Machine class handles that exclusively. Messages sent from 
the Operator and Process classes to the system devices can originate from several sources, including the Part Program 
interpreter the User Interface. Push Buttons on the Console or Jog Pendant, or a Sensor Interface Appl.cat.ons can 
communicate with the Kernel through any or all of the system classes. For specific functions, a software engineer may 
bypass a class and connect an application directly to the next class or another class down. This is accomplished 
through the standard message formats supplied for each object component in the system. 

The present invention is designed as a series of autonomous processes rather than a monolrthic piece of software 
which is typical of embedded software systems. As such, a reliable and predictable interface is required for inter- 
process communication. The details of the communication are encapsulated into an object referred to as the -Trans- 
porter- or transport layer. This object is instigated by each process that intends to communicate with other processes. 
Communications to other processes are requested by symbolic name. 

A directory of processes allows for identifying the various processes by symbolic name. A continuously running 
process commonly accessible process referred to as -Directory Services- allows all the processes connected with the 
system to register their existence, symbolic name, and communications channels. Periodically. Directory Services 
interrogates all the registered processes to determine if they are still active. If any processes is determined to be 
inactive it is removed from the directory and its communications ports closed. This commonly accessible process, 
having a predetermined message protocol, allows the other processes to be independently developed and maintained. 

A message object is defined as the base class for the data to be transmitted between processes. The message 
object contains all of the fundamental information necessary for routing information to the other processes. Specific 
derivations of messages are inherited from the message base class. The contents of these derived messages have 
commonly defined characteristics. Messages contain identifiers that inform the recipient process of the action to be 
carried out or the type of information being transmitted. The identifiers are designed as objects so that the spec.f.c 
details of the ordering of data is transparent to third parties. Also, this allows for messages to be used as base classes 
for other message classes not yet conceived. 

The messaging approach to inter-process communication facilitates the independent development of processes 
for interconnection with the system. The Transporter uses operating system features to implement the actual message 
35 transmission. If a different operating system is used as the core of the system, the Transporter layer may easily be 
exchanged with no impact on the rest of the software. In most conventional systems, moving a system to ano her 
computer platform creates significant modification of the system software. With the present invention s objector.ented. 
message passing approach, the system may be more readily moved to another computer environment. This message 
passing approach also limits the impact of software flaw because clearly refined interfaces and formats play a s.gn.f- 
\o icant role in building and preserving robust software. 

7 The general format fo. messages sent between classes is sei up as a data st. ucture conta.n.ng a common header 

and the arguments that are unique for each specific message. The header includes several variables that are common 
to all messages. The messages are designed to be variable length for efficiency. The message type is a static identi- 
fication number which is unique to the class of message being sent (e.g., a calibration message). The transacuon 
« number unique for each specific message transmission, is assigned at the time the message is sent and is used to 
match responses to the messages. .,. . Iiie . 

The response message is set up so that it uses the request message's ID and transact.on field, and the status is 
set to "received' or "completed- or "denied' as required. This makes it is clear which request is assoc.ated with the 
response Responses have no arguments assocated with them. Anything that requires arguments to be passed « 
» considered to be a new message. For example, the response to an lOSendNode message is an lOlnfo message with 
the data field passed as an argument. A Sample message structure is as follows: 
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/* The message header includes information about th 

message itself */ 

typedef struct lc_header_type 

{ 

int msg_size; /* Length of message */ 

int header_size; /* Length of header info */ 
lcjnsg message; /* The enumerated message number */ 
int transaction; /* The message transaction number */ 
enum type; /* The type of message (request / 

response) : 

0 - this is a request (set by sender) 

1 • request received (set by receiver) 

2 = request completed (set by receiver) 

3 = request denied (set by receiver) 

4 . no service available (set by receiver) */ 
} lc_header_type ; 

operations that may change from one mach.ne to ££ies may ™ jn t egrator may take advantage of 

Logic Controller program. In addition to us,ng new £^^^£^2^ op 9 era ti 0 ns that allow interactive 

process such as a hole-making drilling ooerat.on wrth pecking, the W*™*™**'™^* the exact movements 
^hereby defining the X. ™— a mining operation 

of the drill dunng the ^^^Jr^Sud. means for defining whether the shape to be milled » 

to be used to shape a workpiece. The object may tunner Inc . , d seque ncing status 

to be removed from the workpiece or left remain-ng packaged 
m eansrepresen r eo, = Me Df nQ modrfjcatlon . These 

The Machine Cass forms a device-onenteC I .n "^^^^^^^a^ the device responsibilities 
and canned cycles. The Machine c ass = s, ^^^.^ mon Ls the operator programs' 
between the operator programs and th Kernel. Tne ^ cn ' n ^ c . d Kerne , Eacn application has a copy 

connections to the Kerne, and hand.es messages bet ^ h ^ data assures that all appli- 

of the Machine class included in order to interface in a common way to the Kernel, bnareo 
cations use the same Machine class state information 
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Since the Machine class uses object-oriented design, it contains objects that define specific devices with possibl 
functions for each device. For example, some possible functions of the spindle object may be run, clamp, and stop. 
The object's data describe the speed range and current speed. An operator program may not necessarily use all of a 
Machine class object's functions, but the functions are available and supported by the Kernel. 

Typically, a copy of the Machine class will be attached to each operator application being used in order to provide 
a common interface to the Kernel. In addition, a customer may extend the functionality of the Machine class being 
used, as long as the same Machine class is being used by all operator programs. One embodiment of the Machine 
class contains the following objects: Push-button Console. Jog Pendant. Axis. Axis Group. Spindle, Tool Changer. 
Coolant and Lube. 

The Kernel provides mechanisms for coordinating multiple, servoed axes and to provide discrete I/O control. The 
CNC applications communicate with the Kernel components, the Logic Controller and the Motion Controller, through 
the Machine class. These Kernel components decide how to implement the operator programs' commands for the 
hardware provided. 

The Motion Controller provides multi-axis coordination as in most commercial CNCs. In its basic form, it controls 
five coordinated axes plus one spindle and two auxiliary axes. In addition it supports several types of interpolation 
algorithms including linear, circular, elliptical, helical, and polynomial. Applications communicate with the Motion Con- 
troller through the Machine class message interface. 

The Logic Controller (LC) contains two programs: programmable ladder logic and the LC engine. The LC uses a 
window-based programming environment either off-line or at the Operator level to simplify production of a logic program 
to run on the LC. The LC also has software tools to change, debug, and monitor the operation of the ladder logic. 

The Platform Services class of the present invention provides the structure that allows operator programs and 
third-party software to connect to the system and communicate with other software applications. There are four services 
that control system connection and communication: 

Initialization Sequence - a file, similar to a PC's autoexec.bat file, listing ail operator programs in the order that 
they will start during start up: 

Directory Services - a registry of all active programs; 

Machine Configuration Library - a shared memory area to store default machine parameters for application con- 
figuration. This is similar to the win.ini file in the Microsoft Windows system; and 

Exception Reporter - collects, organizes, stores and distributes all errors of interest to the active applications 

Directory Services contains a 'phone book* that lists all running applications. Applications register with Directory 
Services and receive addresses of the other applications with which they need to communicate. Directory Services 
does not assume any specific communications connections. This means that the system is dynamically configurable 
to allow addition of other applications that use the interfaces of an embodiment of the present invention. Applications 
store the addresses they receive from Directory Services in their own directories. Applications, such as the Kernel, 
that need machine configuration parameters can retrieve those parameters from the shared memory where the Machine 
Configuration Library stores the information. 

An operating system usable in connection with the present invention complies with IEEE- - ! 003.1 POSIX (a standard 
for application programming interface for UNIX) and the IEEE-1003 4 POSIX standard that defines real-time extrin- 
sic s. TIvs embodiment uses the i ynx operating system (LynxOS). a real-time. UNIX-like, operating system trst ru.is 
on any 386 PC/AT or greater comoatible computer. LynxOS lias these characteristics: (1 ) Compliant with POSIX 1003. 1 , 
POSIX 1003.4 real-time extensions and POSIX 10C3.*;=i threads interface; (2) Full UNIX compatibility (binary and 
source with System V, source with BSD 4.3): and (3) Completely deterministic, including Multi-tasking with user-defined 
priority levels. Multi-threaded support for real-time ADA. Offers demand-paged virtual memory, Runs off-the-shelf In- 
teractive UNIX System V software without recompilation. and Networking and communication facilities including TCP/ 
IP and NFS. The LynxOS development tools including over 170 UNIX-compatible utilities and the standard UNIX li- 
braries may also be used. The tool set used in one embodiment supports DOS I/O facilities. Debugger software, Re- 
entrant device drivers, Compilers for C, FORTRAN. Pascal. BASIC, and ADA. GNU Package (GCC. Emacs. GDB, 
C++), X Window System, Motif, Network File Sharing (NFS) and Transmission Control Protocol/Internet Protocol (TCP/ 
IP). 

The Device Drivers class forms the interface between the operating system and the hardware devices such as I/ 
O peripherals (e.g.. serial communications ports), video displays, and mass storage devices. The operating system 
calls these drivers when a device is installed (at boot time or dynamically) and when application programs need to 
access a device. The device drivers in the embodiment are capable of handling multiple devices and respond rapidly 
to high-priority tasks. The present invention contains the following types of drivers: PC/AT keyboard and serial mouse. 
Analog input/output card. SCSI device driver. Floppy disk device driver. Ethernet interfaces. Internet message and 
transmission control protocol. Internet protocol and protocol family. Internet user datagram protocol. Pseudo terminal 
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iniflrface NFS client I/O and server drivers. CANbus. and MATRIX4 
driver, Hard copy and video terminal interlace, iNt-o 

Detailed Description 
s Overview - Hardware 

m- of a tvoical CNC mach.ne on which the control system of the present invention may 

Fig. 1 is a schematic d.agram of a typical gnu mac ™ orocessina unjt n and its associated motherboard, 

operate. A standard PC-com P atib,elSAbus 10 »^^^ C ^^^^X 12 . which may alternatively 
preterm an inte. 80486 ..ass interlace to network 13. Mass storage 
w be connected directly to the motherboard^ ISA bus 10 ™* y J reeled to ISA bus 10, as are standard 

„ sys..rn. According* CANbus interna card 

rnac** nardwara ^^^^,^^^^2^. „ CAN*,. in.ar.aca ,6 and CANbus cabla 

pendant 21 , and servo motors 25, 26. In general, mown motors 22-26 and/or the axes 

!,. provid. msan. ,0, 3 — " * T 

_ or tool fixtures connected thereto. Servo motors ^ ^ c , p jndle wnich rotate s a cutting tool. 

^ESrrSU ..andard cards inc.ud.g ^nSTCSSSC-'S -SS 

,o anach nodas .o ,he sy,,am ,a,ha, .ban inser, cards ™ ™ ^^c^Tcr-HS" and "PSI— 

,o„ and ,a,iabili,y nigh. Standard board •^T^^^ nooas » ,ba ays.an? Tha keyboard may be looatad 

SenS T " S a sy S ,enVs » — — * « CANbus. a "™"™^ 

,„e indusuy standard f^^^^T^^o, cos,s, inoraase more, con.ro. ays.am performance. 

The system uses the MATRIX4 to decrease system y . , 4 , poS jtion controller 

and create component sourcing options for the customer. ^^^J^J^^ a u S er to adapt the 
arable on bo:, the ISA and VME host plat! orms. The ex^my of J^^^'g.^ DC br „ sh:8SS , ,,d 

there are changes in the environment or operating cond.t.ons. 
Overview - Qhject Orien ted Systems 

" Anove.iewofthebroadcategoriesofthesott^^^^^^ 

tion is shown in Fig. 2. In the Operator Cass are software TO™" 9« era lly^ ? communica tes 
(PPI) or user interface. This type of software ,s generally well-known '"^^'^^^ p £ se . The PPI may 
She in.ormat.on it obtains to the remaining ^^J^^^^^^; the user to specify a data file 
so either interrogate the operator to input » ^ZZT^ceZoLZ about the part is obta.ned, the 

having a digrta.ly stored part manu ^^V^^SZ^^ described betow. 

PPI dynamically creates appropriate objects m the Pr ^ ss ^" . and pf0gramm jng object-oriented design 

The control system of the present invention "•"^^^STi or P gan 9 (2ed jnto ob.ects. Software corn- 
means that software components are created from data Jo parts: data ano methods Objects 
55 ponents communicate through messages sent ^J^^^l ^dle °oo. changer, or type o. motion) An 
are abstract representations o, the basic are instructions, programs, proce- 
^cS^SSS: STuTc^ ^ something happens So a spind.e objeefs methods may 
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be initialize, run. orient, speed override, and stop. The object's data describe the speed range and current speed. 

Using object-oriented programming, objects can be quickly created using a class, the blueprint for the objects. 
The class establishes the basic variables that are common to all of its objects, and the new objects inherit these common 
characteristics from the parent class. This feature allows the software engineer to build on existing design and code 
by creating more specific objects from the easily reused code in the general class. For example, a software engineer 
can use a general class of characteristics for a 'device* to create a model of a more specific device such as a spindle. 

A method belongs to an object and indicates how to perform an action or how to react when an action is performed 
on the object. The system may only access data through the methods, if at all. Methods, therefore, hide an object's 
data and send messages to perform operations. This isolates dependency on a particular data structure thus permitting 
new features to be added without changing the arrangement of the original objects. This structure protects the data 
from the damage that commonly occurs during changes in monolithic, proprietary systems. 

As with data characteristics, methods can also be inherited from the parent class when a new class or object is 
created. Of course, the new class or object may use the method or create a different version of it. Different objects can 
use id ntical methods. Therefore, a software engineer writes the code for the method only once and then reuses it 
after that. The reusability of existing object-oriented -code makes development and modification faster because there 
is less to write and maintain. An additional benefit of using object-oriented methods is the localization of change. Data 
hiding isolates code from other code and reusing methods removes the need for switch statements and other references 
throughout the code to the system's condition or processing state. This limits the ripple effect of changes and makes 
it easier to maintain large, complex programs. 

The control system of the present invention software contains class libraries, of machining software. These libraries 
contain machining procedures and functions that can be called with an expected result. These libraries are grouped 
into object-oriented classes that may be used as is and/or extended. The core libraries contain the most basic char- 
acteristics needed for primitive operations. 

The software employs a bi-directional messaging interface to facilitate communication between components. Mes- 
sages are passed between the CNC applications (PPI and Process Class) and Kernel. Communication from the ap- 
plications to the Kernel differs from communication between the applications in that Kernel communication is more 
precisely defined for the Kernel. Each component communicates through messages. These messages may have dif- 
ferent requirements. Messages are managed for efficient communication. Unordered, independent messages are ex- 
ecuted immediately. Ordered, dependent messages are queued. A queue message is not executed until the previous 
message is complete, and each component maintains a separate message queue. 

A key feature of the CNC control system of the present invention is the ease with which existing systems can be 
brought onto the new platform. The obvious advantage of this feature is that it preserves features of existing systems 
while providing a migration path to future technologies. There are two ways a user may take to move existing software 
to the control system of the present invention: (1 ) porting 'C systems for immediate use. or (2) conversion of procedural 
code to C or C++. 

Machine Class 

The Machine Class is an object-oriented interface to the Kernel and Process Class. This class contains the ma- 
chine's device-specific application procedures to hide the complexity of the Kernel and the message interface frcm the 
CNC applications Tiiis U accomplished through the interface between the Machine Class and the CUC applies! ions 
(Process Class/PPI). Applications call standard functions to the Machine Class objects which sends a message to the 
Kernel. The Machine Class objects handle at! communication between the Process Class objects and the Kernel in- 
cluding the creation of the communications port, use of appropriate communication functions, and passing messages 
back to the CNC applications. The specific Machine Class responsibilities are allocation of resources and connection 
to the Kernel, message handling between the Kernel and the CNC applications, and device state monitoring and man- 
agement. 

When the system starts up, the Machine Class allocates the resources that the application needs and creates a 
port to the Kernel from each CNC application. After the port is created, the Machine Class logs in to the port creating 
a two-way connection between the Kernel and each running application. This allows messages to be sent back and 
forth from the applications to the Kernel. Multiple copies of the Machine Class may be used in the system. In fact, it is 
customary to attach a copy of the Machine Class to each CNC application being used. 

Kernel 

The Kernel Class is the mechanism through which CNC applications control machinery. The Kernel provides mech- 
anisms for controlling discrete I/O and coordinating motion axes. This gen ral controller can be used in a variety of 
machining applications. The Kernel contains two components: Logic Controller and Motion Controller. The Motion 
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Controller performs multi-axis coordination. In its basic form, it controls five coordinated axes plus one spindle and two 
a °T^Z7ZlTsu PP ons severa. types of interaction algorithms including linear . circular, e.hpt.al. he.,cal. 
and polynomial Applications communicate with the Motion Controller through a message interlace. 
The S^«Jff(?C) engine executes ladder logic/GRAFCET programs to contro. the machine at the lowest level. 
There a're S ^ programs the LC engine executes: the user program and the system program. The LC a.so has tco.s 
to change, debug, and monitor the operation of the ladder logic. 

Operating System 

The real-time, UNIX, execution environment provides all of the standard advantages of a real-ti ™ 
with its diagnostics and response capability, .n addrtion. X Window is a standard, graphical, user interface . X W^w 
permrts a variety of input devices (e.g., mice, keyboards, graphic displays) to be simultaneously shared 'by several 
progra-s. This flexibilrty allows developers to .everage their areas of expertise wthout being «»^"°"»" 
basic system graphics. This window-display interface a.so allows the user to run one mach.ne ^f^***™** 
on anoLr, an definite advantage for a CNC application. Mot* manages the ™^ ^^Z^Z 
manager allows the user to control the size, location of windows on the screen, and 'dentrf.cat.on of the active w.ndow 
Ss software a.so provides a library of X Window items to use in system development. TCP/IP .s a network ^pro^col 
thatVuns on Ethernet. It allows X Window to perform network transparent activrt.es such as remote procedure calls. 
Its file sharing capabilities means that programmers do not need to download files. 

Platform Services 

The Platform Services Class provides these functions: 

Initialization Sequence - a file listing all applications in the order that they will start during power up: 
Directory Services - a registry of all active applications 

Machine Configuration Library - a shared memory area holding default machine parameters: 

Exce^Sn Reporter - collects organizes, stores and distributes all errors of interest to the act^e appl.cat.ons 

Applications register with Directory Services and receive addresses of the other applications with .which they need 
to communicate. Applications store the addresses they receive from Directory Serv.ces .n the.r own d.rec* nes £pfc- 
itions such as the Kernel, that need machine configuration parameters can retrieve those parameters from the shared 
memory where the Machine Configuration Library stores the mformation. 

Messages between the applications use POSIX message queues. These queues, are created f ^; u " t ' me e ^ 
have unique names. Each application receives messages through one instrument, but as when us.ng telephones, each 
pnniiration can communicate with many different applications. 
PP Th1°nit^ation Sequence is the init script file listing all applications in the order that they win start during power 
uo It is executed after the operating system boots. The Initialization Sequence's primary respons.b.l.ties are to. 

Lofcd various CNC system drivers (CANbus. MATRiX4, and the serial port driverj 
Start Directory Services, the Exception Reporter, the Kernel, and the user display 
Create the Machine Configuration Library 
Start listed applications 

A user may create and change this script. It should begin with the device drivers. P ^° r ^ Se ^;^ 
System Other applications in the script may be the CNC applications and the mol.on subsystem and Log,c Control^ 
wrthinThe Kernel To create or change the script, the customer may use an edrtor (V.) or the .nteractrve setup program 
Trie scnpt can also be created automatically with the software installation program. The fo.low.ng * a representee 

initialization sequence script. 
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/ 

# Dynamically installed device drivers 
/ 

dynaminst \ / Devices /MATRIX4 . insttab 
dynaminst \ / Devices /CANbus . insttab 

# 

/ System Services 

0 

/bin/DirectoryServices 
sleep 5 

/bin/ ExceptionReporter 



# 

/ Kernel 
# 

/bin/Kernel & 
* 

# User Applications 
/ 

/Apps/bin/Manual & 

Platform Services Messages 

Messages have a standard grammar using command verbs with possible qualifiers. There are throe types of qual- 
ifiers: 

Structure - defines a type of variables. 

Enumeration - a list of integer values allowing association of constant values with qualifier names. 
Union - a variable that may hold (at different times) objects of different types and sizes. It is used to manipulate 
different kinds of data in a single storage area without embedding any machine-dependent information in the pro- 
gram. 

Required qualifiers begin with a capital letter, and optional qualifiers use no capitals. 
Message Structure 

Messages used by the Platform Services have this basic structure: 
Verb Qualifiers 

A verb describes the message request. The verbs used by the Platform Services* components are - 
Add - establishes a phone book listing for an application 

G t - finds the address of an application or the configuration information in shared memory 
Update • supplies new information for an application 
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Ping - checks on the status of an application (active or shutdown) 

Request - asks to be informed when a condition has changed The qualifiers are data structure names followed by 
the data structure elements. These qualifiers can be composed of other qualifiers (i.e., dynamic data structures). 
Verbs act on the qualifiers. 

Platform Services Schema 

The schema defines the data structure qualifiers for all messages and global data used by Platform Services. 
Platform Services' messages use the following qualifiers: 

• String 

• PhoneListing 

• Description 

• Value 

• FieldPtr 

• FieldCount 

• DataType 

• ErrorCode 

The following qualifier descriptions contain definitions in the form of text and in 'C code and the definitions of the *C* 
code data names. 

String 

String is a structure describing a collection of ASCII characters. The 'C data structure follows: 

typedef struct 
{ 

int length; 
char characters [ ] ; 
} String; 

length = number of characters in the string 

characters = an array of letters, numbers, and/or symbols 

Description 

Description is a string explaining a variable concept (e.g., an error condition) in a message. The 'C* data structure 
follows: 

typedef String Description; 



FieldPtr 

FieldPtr is an index in to the Machine Configuration database. The 'C data structure follows: 

typedef int FieldPtr; 

FieldCount 

If the field is an array the FieldCount indicates the number of elements in the array. The 'C data structure follows: 

typ d f int FieldCount; 
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PhoneListing 

PhoneListing is a data structure representing the address of an application in a directory listing. The 'C* data 
structure follows: 

typ def struct 
{ 

string processName ; 
portName Name ; 
int processID; 
} PhoneListing; 

processName = name identifying the application 

portName = name of the connection port for the application identified 

processID = integer code identifying the application 

DataType 

DataType is an enumeration of data representations. The 'C data structure follows: 

typedef enum 
{ 

undefined; 

integer; 

floatingpoint 



} DataType ; 

Undefined = data type not specified 
Integer = data consisting of whole numbers 
FIcvUingF oint = floating point data 
String = data expressed with characters 

Value 

Value is a union representing a variable data type. DataType defines the data's size and type. The 'C data structure 
follows: 

typedef union 
{ 

int integer ; 
double floatingpoint ; 

String string; 
} Value 
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integer = data consistingof whole numbers 
floatingpoint = floating point data 
string = data expressed with characters 

ErrorCode 

ErrorCode is an enumeration of exceptions. The 'C data structure follows: 



typedef enum 
{ 

NoSeverity; 
Information; 
Warning; 
Fatal; 
} ErrorCode ; 

NoSeverity = error of uncategorized severity 

Information = error message providing information only (no action required) 
Warning = error indicating application is having difficulty completing the task 
Fatal = error indicating application is not able to complete current task 

Directory Services 

Directory Services functions as a registrar for the system applications. The responsibilities of Directory Services 
are to - 

Maintain a list of applications in the system 

Periodically check (ping) applications to see if they are still running 
Provide queue addresses of registered applications 

Applications register in the Directory Services' phone book by listing their unique ASCII names. Then before an 
application can communicate with another application, it requests the POSiX message queue address from Directory 
Services' phone book. Each application has its own phone book. It lists only the addresses of other applications with 
which rt needs to communicate. 

Application Shutaown 

Directory Services periodically pings all registered applications tc be certain that th« y are still running. If an appli- 
cation has shut down, Directory Services removes the shut-down application from the list of registered applications, 
destroys its copy of that application's port connection, and informs all remaining, registered applications that the ap- 
plication has shut down. At that point, the applications decide if they need to disconnect from the shut-down application. 
Applications clean up after disconnecting by removing the reference for the shut-down application from their own di- 
rectories. 

Messages to Directory Services 

Applications send messages to Directory Services to register in the phone book and to retrieve phone book entries 
of other applications. These messages use the standard message structure described previously. 

Add 

An application may send an Add message to Directory Services to establish a phone book listing for the application. 
The Add verb uses the PhoneListing qualifier with the required elements Name. PortName and Process! D. The mes- 
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sage structure is • 

Add PhoneListing <Name> <PortName> <ProcesslD> 
Elements 

The elements for the Add verb can use a string of ASCII characters. 

<Name> ASCII character string 

<PortName> ASCII character string 
<ProcesslD> number representing the process ID 

Sample Message: 

Add PhoneListing LC LCportll94 151 

Expected Responses 

When Directory Services adds the new entry to its phone book, an 'Added' response is sent to indicate that the 
phone listing was successfully updated. A 'NotAdded' response is sent if Directory Services was not able to update its 
phone listing. 

Added PhoneListing <Name> <PortName> <ProcesslD> 
NotAdded PhoneListing <Name> <PortName> <ProcesslD> 
Description <errordescription> 

Sample Response: 

Added PhoneListing LC LCportll94 151 

Get 

An application may send a Get message to Directory Services to find the address of an application with which it 
wishes to communicate. The Get verb uses the PhoneListing qualifier. The message structure is - 
Get PhoneListing <ProcessName> 

Elements 

The ProcessName qualifier is a string of ASCII characters. 
<ProcessName> ASCII character string 

Sample Message: 

Get PhoneListing LC: 

Expected Responses 

When Directory Services retrieves an entry from its phone book for a requesting application, it sends a 'Got' re- 
sponse to indicate that the phone listing was successfully retrieved. A 'NotGotten' response is sent if Directory Services 
was not able to find the phone listing. 
Got PhoneListing <Name> <PortName> <ProcesslD> 
NotGotten PhoneListing <Name> 

Sample Response: 

Got PhoneListing LC LCportll94 46 
Messages from Directory Services 

Directory Services sends messages to applications under two conditions: 
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• Checking to see that th^pplication is still active (Ping) 

• Informing applications that another application is no longer active (Update) 

These messages use the standard message structure described previously. 
Ping 

The Ping verb uses the ProcessName qualifier. The message structure is - 
Ping <ProcessName> 

Elements 



<ProcessName> ASCII character string 
is Sample Message: 



Ping LC 



Update 

Directory Services sends the application an Update message to inform an application of a change in another 
application's status. The Update verb uses the PhoneListing qualifier and has this structure - 
Update PhoneListing <Status> <description> 



25 Elements 



<Status> enumeration of status conditions 

<description> ASCII string of characters describing the status condition 



30 Sample Message: 

Update LC shutdown 

Machine Configuration Library 

35 The Machine Configuration Library provides default parameters for applications in a shared memory area. This 

service's responsibilities are to - 



45 



Load and distribute initialization parameters from the file system 

Distrib'Jie parameters to applications Some common parameters may be maximum acceleration, maximum RPM 
for the spind and travel limits and feed forward gains for each axis. Applications access these oarameters under 
three circumstances: 

During application start-up for initialization parameters 
During run time when operational parameters are needed 

When tuning or another operation makes it necessary for an application to refer to its configuration parameters 

This parameter library uses a C++ object, System Variables, to read and write data in the globally accessible shared 
memory area. The library also contains utilities to create. load the configuration, print, list, save, restore, and remov 
the information in the System Variables memory region. 



so System Variables Object 

The System variables object supports seven data types: 



Bytes 
55 Strings 
Doubles 
Integers 
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Short Integers 
Long Integers 

This object also includes methods for saving and reading the parameter information to and from disk. The System 
Variables methods are listed below: 

BasePtr - returns the base pointer to the shared memory. 
Close - closes a connection to the shared area. 

Field - calls the SVField object (described in the following section) to find a field specified by the field name. 
FieldCount - gets the number of elements for the field and returns the parameter count. 
FieldSize - gets the size of the field and returns the parameter size. 

FieldType - gets the data type and returns 'B* for byte, T for integer, *D' for double, 'S' for string, 'H* for short integer, 
or V for long integer. 

FileName - returns the configuration file name used to define the shared data area. 
Some additional System Variable methods are listed below: 
Get - finds configuration information in shared memory. 

Update - places new configuration parameters in shared memory for an application. 
GetField - traverses the list of fields in the shared area. 
Name - returns the shared area name specified in the configucation file. 
NumberOfFields - returns the number of fields defined for the System Variables. 
PostSemaphore - releases the semaphore used to synchronize access to the shared area. 
Remove - deletes the shared area completely from the system. 

Restore - places a saved binary copy of the configuration parameters into the shared area. 
Save - makes a binary copy of the configuration parameters and places it on the disk. 
Size - returns the total size in bytes of the shared area (not the amount of shared area being used). 
Wait Semaphore - gets the semaphore used to synchronize access to the shared area. 

The PostSemaphore and WaitSemaphore methods allow a program to access the shared area and send several mes- 
sages without the overhead of getting and releasing the semaphore for each Get and Update message. This approach 
saves time. 

SVfield Object 

The System Variables object uses the System Variables Field (SVfield) object to describe each field. Using this 
object improves efficiency of the field access function by providing detailed field information and eliminating the search 
for individual fields. ~i 

This object contains the following methods" 

Name - supples t'*.e name of the field (up to 31 characters including a null terminator). 

Type - supplier the field data type ('B' for byte, T for integer, *D' for double, 'S* for string, >!' for short integer, or *L' 
for long integer). 

Count - supplies the number of elements that may be stored under the field name. Elements are numbered be- 
ginning with zero. 

Size - supplies the size of each field element. In 386/486 systems, integers and doubles are stored in four bytes 
while strings are variable length. 

Utilities 

There are several utilities available to create and manage the Machine Configuration shared data and the memory 
area: 

SVcreate - builds a configuration file. 

SVsize - checks the configuration file's size and recommends a minimum size. 

SVprint - displays the field name, data type (B. I. H. L. D, S). the count (number of elements), and the size of each 
field. 

SVIoadConfig - places the default values into the shared memory area. 
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a n^showing all of the data values currently storeo^^r 
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SVIistData - creates a fileshowing all of the data values currently storecnnthe shared memory area. 
SVsave - makes a copy of the shared memory area under the file name specified in the configuration file. 
SVrestore - dumps the shared area in hex bytes to be used for detailed debugging tasks. 
SVremove - deletes the shared area from the system. The configuration file and any binary 'save* files are left intact. 
5 SVshmdump • displays the shared area in hex bytes. This can be used for low-level debugging. 

Messages to Machine Configuration Library 

Applications send messages to the Machine Configuration Library. 

io Get 

An application may send a Get message to the Machine Configuration Library to access information. It uses this 
format: 

75 Get Qualifier 

Get FieldPtr 

This message requests the <fieldPtr> or the Field Description. If the <fieldPtr> is zero, then this message requests 
the pointer to the description <name>. If the Description is empty, then this message requests the description of the 
/ field pointed to by <fieldPtr>. It is an error if the <fieldPtr> is zero and the Description to be empty. 
' Get FieldPtr <fieldPtr> Description <name> 



Elements 

The elements for the Get verb are - 

<fie!dPtr> Pointer to a field in the Configuration Library 
<Name> Name of the Field 



Sample Message: 

Get FieldPtr 0 String "MaxTravelX' 
35 Expected Responses 

Configuration Library returns the following: 



Got FieldPtr <fieldPtr> Description <name> 
NotGctten Fie-dPtr <fieldPtr> Description <name> 
Description <ororDescrip:ion> 1 

Sample Response: 



45 Got FieldPtr 253 String 'MaxTravelX' 

Get Description 

This message is used to request information about the Fields in the Machine Configuration Library. The Fields can 
be described either by using the name or a field pointer. 



Get Description <name> Qualifier FieldPtr <fieldPtr> 

Get Description <name> Qualifier Description <fieldName> 

Elements 

The elements for the Get verb are - 

<name> name of the information requested from a field: 
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Field Count 
Field Size 
Field Type 
Field value 

Qualifier The Qualifier is a place holder for the results of the Get. It also specifies the data format (int. float, 

string) of the desired result. 
<FieldName> Name of the field 
<FieldPtr> Pointer to the field 

Sample Message: 

Get Description "Field Count - int <count> FieldPtr 23 
Get Description 'Field value' Floatingpoint <value> 
Description "MaxTravelX" 

Expected Responses 

Configuration Library returns the following: 

Got Description <name> Qualifier FieldPtr <fieldPtr> 

Got Description <name> Qualifier Description <fieldName> 

Sample Response: 

Get Description "Field Count" int 10 FieldPtr 23 
Get Description "Field value' Floatingpoint 23.5 
Description "MaxTravelX" 

Update 

Update Description 

This message is used to change information about the Fields in the Machine Configuration Library. The Fields can 
be described either by using the name or a field pointer. 

Update Description <name> Qualifier FieldPtr <fieidPtr> 
Update Description <name> Qualifier Description 
<fieldName> 

E'ementr 

The elements for the Get verb are - 

<name> name of the information requested from a field: 

Field value 

Qualifier The Qualifier is new value for the field 

<FieldName> Name of the field 
<FieldPtr> Pointer to the field 

Sample Message: 

Update Description "Field value" int 10 FieldPtr 23 
Update Description "Field value" Floatingpoint 23.6 
Description "MaxTravelX" 
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The Configuration Library returns the following: 
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Updated Description <name> Qualifier Field 
Rr <fieldPtr> 

Updated Description <name> Qualifier Description <fieldName> 



Sample Responses: 
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Updated Description "Field value" int 10 FieldPtr 23 
Updated Description "Field value" Floatingpoint 23.6 
Description "MaxTravelX" 
Exception Reporter 
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The Exception Reporter receives all unsolicited error messages (e.g., servo faults) sent by the Kernel. The Ex- 
c ption Reporter responsibilities are to - 

• Receive error reports for applications and Kernel 
20 • Distribute error reports to applications 



This makes error handling uniform across ail applications. It collects and organizes the errors for applications that have 
registered with the Exception Reporter to receive particular types of messages. In addition, the Exception Reporter 
keeps a list of all current pending error messages. When an application starts up and checks in, it can receive all 
25 messages of interest to it. 

Applications specify the severity and/or category of errors they want to receive. So an application may tell the 
Exception Reporter to notify it when any I/O errors are generated. Another application may want to be informed only 
of the fatal errors that shut down the machine. 

30 Error Messages and Severities 



The Exception Reporter filters errors for applications so that the applications only receive the messages they need. 
There are two basic types of messages in the Exception Reporter queue: 



Latched messages 

When a one-shot message arrives, the Exception Reporter determines which applications need to receive the 
message, sends copies of the message to those applications, and then removes the message from its queue. When 
40 a latched message arrives, the Exception Reporter determines which applications need 10 receive tiie message 3nd 



sends copies of the message to those applications. However, latched messages arc not removed from the queue until 
another message arrives instructing the Reporter to remove the stored message. The latched messages that have net 
been cleared form the group of current pending messages that a newly started application may need to receive. 
The messages may have three severities: 



Information - describes a condition that may be of general interest to other applications. 

Warning - indicates that operation of the machine has halted though the power is still on. The operator may need 
to take some action to continue operations. 

Fatal - tells the system applications that the servo amp has been shut down and the power has been taken away 
from the machine control hardware. The operator must take some action to resume operations. 

There are also categories of errors that may be of interest to applications: 

Motion 

Logic Control 
Device Layer 
Directory Service 
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One-shot messages 
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r Of course, the customer may also define additional error categories. Then when a message arrives, the Reporter 

" matches its severity and category with the types of messages each application indicated it wanted to receiv . 

For example, an application may need only the fatal, motion control messages, and another may need all logic 
control errors. 

5 After the messages are filtered in this manner, the one-shot messages are broadcast to all interested applications 

and removed from the queue. All latched messages are broadcast to interested applications and kept in the queue 
until specifically removed by another message. 
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Message Formats 

Messages sent to the Exception Reporter either report an error or request error information. There are two verbs 
used in the Exception Reporter messages: Update and Request. 



Update 

To inform an application of an error condition, the Exception Reporter sends the application an Update message. 
The Update verb uses the Error qualifier and has this structure - 
Update Error <ErrorCode> <description> 



20 Elements 

^ <ErrorCode> enumeration of exceptions 

<description> ASCII string of characters describing the error 

25 Sample Messages: 



Update Error Fatal loss of encoder; X axis 
Expected Responses 

The Exception Reporter sends the error message to an application. If the error message was successfully sent, it 
returns an 'Updated' message. If the error message was not sent successfully, it returns a 'NotUpdated* message. The 
responses use these formats: 



Updated Error <ErrorType> 

NotUpdated Error <ErrorType> <ErrorValue> Desc 
35 <errordescription> 
Request 

An application may send a Request message to Exception Reporter to ask that it be informed of specified error 
conditions. 

Request Ei rorCrvde <Code> 
Elements 

<Code> enumeration of exceptions 

45 

Sample Message: 



Request ErrorCode Fatal 
Expected Responses 

There are two expected response verbs: Requested and NotRequested. Both verbs use the ErrorCode qualifier 
Requested ErrorCode <Code> 
NotRequested ErrorCode <Code> 



Operator Class 

Operator Class applications include part programming software. The conversational language used in a fully- 
featured package has a question/answer format using multiple choice and fill-in-the-blank questions, as well as clearly 
worded operator prompts. To further simplify part programming, the system displays graphic illustrations of plan view. 
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side views, and/or an isometric view with dimensional scaling in jhjJtf&d Z axes. 
The conversational part programming package features th following. 

I ^!S£SS Graphics Verification for Conv rsationa. and NC programs 

• Programmable Safety Areas 
'No-Calc' Programming 

• Estimated Run Time 
99 Tool References 

. Automatic Speed and Feed Calculation 

• inch/Metric Programming 

• Modal Parameter Blocks 

• Automatic Rough/Finish Pass 
Data Block Search 

After the operator comp.etes a part program, there are several additiona. features of the software that can be used 

to improve efficiency and accuracy: 

Error Checking 
Test Run Function 
Program Review 
Program Text Printout 
Graphics Printout 
Upload/Download Utility 

The au,oma,ic ca,cu,a.,c ,ea«ure ^^J-J^^SST^SS^ 

'Y' end coordinates. 
Cutter Compensation 

When ginning th. pa, program, the operator ^^^Z'^Z^'^^ 
au ,c<na.icaUy atlo* (o, the diameter ot the tod ^ «™r» £ £C ^ „ die equal to the radius 
milUng segments. With cu.te, °°«^™J^ ™J£Z^J<™ X* « >" conventional milling or the left to, 

nrogrammmg a block. 
Packaged Cycles 

ing and reaming. Sir.ce the system contains packaged cycle* the operaor can specie W » ^ 
J, the necessary variable in.orma.ion. ^•'^ operator simp, y specities ,he 

zzzzzi 'zzzzzrz^zz^ - — s - - - durin9 ,n * 

pecking process. 
RS-274-D Package 

■m ™«nti Q n a i NC (G-code) programming capabilities. This package allows the op- 
A RS-274-D package provides conventional NC (e-cooej prog y ^ /CAM ljcatjons Q r other peripheral 

re^er^^^ 

NC editor in this package has the following features: 
• Character insert or overwrite modes 
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• Optional sequence numbers 

• _ • Automatic sequence numbering by a programmable increment 

• Block-to-block cursor moves (forward and backward) 

• Character-to-character and word-to-word cursor moves (forward and backward) 
5 * Jump to program beginning or end or scroll up and down on one page 

• Jump to block or sequence number 

• Jump to or replace a matching NC word 

• Automatic syntax checking of NC data blocks 

• 10-element tag queue for 'bookmarking' the program 
10 • Jump to one of the tags 

• NC block insert and delete 

• Copy, move, or delete a range of NC blocks 

• Interaction with the graphical system for program verification 

is NC programs can be loaded into conversational PPIs through this interpreter. 
PPI Messages 

The Part Program Interpreter messages have the standard grammar using command verbs with possible qualifiers. 
20 There are three types of qualifiers: 

i Structure - defines a type of variables. 

Enumeration - a list of integer values allowing association of constant values with qualifier names. 
Union - a variable that may hold (at different times) objects of different types and sizes. It is used to manipulate 
25 different kinds of data in a single storage area without embedding any machine-dependent information in the pro- 

gram. 

Required qualifiers begin with a capital letter, and optional qualifiers use no capitals. 

30 Message Structure 

Any of the Part Program Interpreters used in the system have the same basic message structure: 
Verb Qualifiers 

35 a verb describes the message request. The verbs used by the PPI are - 

Interpret - finds information about the axis positions and speed 
Update - supplies new information about the axis position and speed 

The qualifiers are data structure names followed by the data structure elements. These qualifiers can be composed 
y*o of cthor qu&i.riers (i.e., dynamic data structures). Verbs act on the qualifiers. 

PPI Schema 

The schema defines the data structure qualifiers for all messages and global data used by any Part Program 
*5 Interpreter (PPI). The messages use the following qualifiers: 

• String 

• Description 

so The following descriptions of these qualifiers contain definitions of the qualifiers in the form of text and in *C' code 

and the definitions of the 'C code data names. 

String 

5 5 String is a structure describing a collection of ASCII characters. The 'C data structure follows: 
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typedef struct 
{ 

int 1 ngth; 
char charact rs [ ] ; 
} String; 

70 length = number of characters in the string 

characters = an array of letters, numbers, and/or symbols 

Description 

Description is a string explaining a variab.e concept (e.g.. an error condition) in a message. The >C data structure 

follows: 

typedef String Description; 
Interpreter Messages 

Any Part Program Interpreter working in the system must use two standard messages: Interpret and Update. 
Interpret 

The Interpret messages send pieces of an RS-274 program to the Interpreter. 
Interpret Description <programBlock> Prnnrflm 
The interpret message directs the PPI to begin execution of the Part Program. 

<programBlock> RS-274 program block 

Expected Responses 

35 commands are - 

Interpreted <Qualifier> 

Notlnterpreting <Qualifier> Description <errordescription> 
■io Uj.oate 

An RS-274 program » made up of many modals. The initial values of these moda.s can be set using the Update 



25 



30 



45 



SO 



message. 

Update Description <modalName> Qualifier 

<modalName> Name of the Modal to be modified 

Qualifier contains data type and a value for the modal. 



Expected Responses 

The PP. responds with an Updated message to indicate that the modal has been set. If the moda. is undefined. 

an NotUpdating error message is returned. 

Updated <Qualifier> 
55 NotUpdating <Qualifier> Description <errordescription> 
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r Configuration Parameters 
* * 

The Integration Tools, described later in this chapter, allow integrators to modify interactively the behavior of the 
controls as they adapt the controls to the machines. OEMs can modify the parameters for the following: 

5 

• Kinematics 

• Servo Tuning 

• Safety Regions 

• Maximum Feeds and Speeds 
io • Lead Screw Mapping 

• Remote Communications 

• Language 

Version control of configuration files permits the integrator to extend previous versions of parameters and record the 
■ is changes for backtracking purposes. 

Machine Class 

The Machine Class of the control system of the present invention forms a device-oriented interface between the 
20 Kernel and the CNC applications. The Machine Class establishes and monitors the CNC applications' connections to 
^ the Kernel and handles messages between the applications and Kernel. Each application includes a copy of the Ma- 
chine Class to facilitate a common interface to the Kernel. Also, shared data assures that all applications use the same 
Machine Class state information. 

Since the Machine Class uses object-oriented design, it contains objects that define specific devices with all of 
25 the possible functions for each device. For example, a spindle object may have the possible functions of run, clamp, 
and stop. The object's data describes the speed range and current speed of the spindle. A CNC application may not 
necessarily use all of a Machine Class object's functions, but the functions are available and supported by the Kernel. 

A CNC application may also hook into packaged cycles from the Application Tool Kit. These cycles define common 
machining operations such as drill, bore, and tap and operate at a higher level in the control system than the Machine 
30 Class. By using these same Machine Class object methods, a customer may customize and expand the packaged 
cycles to meet specialized needs without concern for the details of Machine Class operations. 

Multiple copies of the Machine Class may be used in the control system. It is recommended that a copy of the 
Machine Class be attached to each CNC application being used in order to provide a common interface to the Kernel. 
In addition, a customer may extend the functionality of the Machine Class being used, as long as copies of the same 
35 Machine Class are being used by all applications. 

Described herein are two functional Machine Classes according to the present invention: (1 ) Milling Machine Class; 
and (2) Sample, generic Machine Class. The sample, generic Machine Class is a simple example designed to assist 
in gaining an gain understanding of the message interface. The Milling Machine Class is one that may be implemented 
for a basic milling machine. 

-\40 

* Miiiinq Machine Class 

The Milling Machine Class allows customers with milling machines to become immediately operational. To use 
his Machine Class, customers simply link to the Machine Class library with their CNC application and gain access to 
he following objects: 

Flow Control 
Push-button Console 
Jog Pendant 
Axis 

Axis Group 
Spindle 
Tool Changer 
Coolant 
Lube 

All of these objects allow a CNC application to grab ownership of the device, initialize the device, monitor its current 
state, and release ownership. When an application has grabbed ownership of a device, it then has the authority to 
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issue action request^ffhat device using the methods provided. ThelMng Machine Class can also be used in com- 
bination with the packaged cycles in the Application Tool Kit to customize the operation of a milling machine. 

Sample. Generic Machine Class 

A sample Machine Class may be used as a pattern to develop new Machine Classes. It contains the minimum 
object-oriented devices with their methods that are needed to operate a typical machine tool: 

Flow Control - controls the communication from the CNC application to the Kernel's synchronous queue. 

Push-button Console - reserves ail necessary buttons and lights on the console for an application. 

^is . allows an application to control an individual axis or joint. 

Axis Group - user-defined groups of coordinated axis moves (e.g., X, Y, 2, A, and B). 

Spindle - basic functions of a machine tool spindle. 

Tool Changer - basic functions of a tool changer. 

Shared Memory 

In an alternate embodiment of the invention, an area of the computer's memory is reserved for the Machine Class 
information. The shared memory contains ownership and state information for each device. Each copy of the Machine 
Class looks at this region to access information about the devices. However, access to this area is controlled so that 
applications can only view and change device information through the Machine Class. 

Rules of Ownership 

Since multiple applications may attempt to access the same device, the concept of device ownership is central to 
the operation of the Machine Class. Ownership of a device means that an application has reserved that device though 
the application may not be using device at the moment. 

The application that 'owns* a device has full access to it while other applications have read-only access. Applications 
are permitted to send messages to devices only if they have ownership of those devices. This minimizes the inter- 
component logic required for any application often used to determine permission conditions for a command. However, 
some decision logic is still needed within each application. 

Systems with only a single application may be structured to never grab ownership of a device. In this situation, 
there would be a single owner of ail devices. 

Communications 

Messages to the Machine Class devices can originate from several sources: 

• Part Program Interpreter 

• User Interface 

• Push Buttons on the Console or Jcg Pendant 

• Sensor Interface 

To simplify system operations and programming, the control system has a specific division of labor between its 
components. For example, the Machine Class does not worry about the Kernel's responsibilities such as trav I limits 
and servo errors. Conversely, the Kernel is not concerned about ownership or devices because the Machm Class 
handles that exclusively. 

This system structure also simplifies system communications and complies with the open systems concept. CNC 
applications may communicate with the Kernel through any or all of the system layers. For specific functions, the 
customer's software engineer may bypass a layer and connect an application directly to the next layer or another layer 
down. This of course, is accomplished through the standard message formats supplied for each control system com- 
ponent. 

Communication Connections 

An application may communicate to the system components in two ways: (l) Through the system layers: or (2) 
Directly to the components. When an application uses the Machine Class layer, three advantages result: 
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1. Automatic message sequencing f9fK Kernel components (Logic and Motion Cori^PBrs) 
, „ 2. Ownership handling (or multiple processes 

3. Simplified communication to devices 

5 The control system permits communication through the Machine Class layer to the Kernel components. To operate 

efficiently, a CNC application's part program interpreter and its user interface (also called a man-machine interface- 
MMI) need the operational simplification provided by the packaged cycles from the Application Tool Kit and the features 
of the Machine Class. 

However, some programs do not need the features of these middle layers. For example, the diagnostic and tuning 
io programs within a CNC application are not concerned with the system's devices or ownership rules. These specialized 
programs can communicate efficiently by connecting directly to the Kernel functions. Another program that bypasses 
the middle layers is the Exception Reporter. It is not interested in the machine devices or even the Kernel functions 
and can connect directly to the messaging functions. 

If a customer is using only one CNC application to control the entire system, that application must manage device 
is access between different parts of the program. . 

Message Schema 

The Machine Class messages use the qualifiers, listed in the schema below, to define the messages. Qualifiers 
20 are data structure names followed by the data structure elements. These qualifiers can be composed of other qualifiers 
(i.e., dynamic data structures). The message verbs, described in the following section, act on these qualifiers. 

String 

25 String is a structure describing a collection of ASCII characters. The 'C data structure follows: 

typedef struct 
{ 

int length ; 
char characters [ ]; 
} String; 



I ngth - number of characters in the string 

characters - an array of letters, numbers, and/or symbols 

DataType 

DataType is an enumeration of data representations. The 'C data struc'jre follows: 



typedef enum 
{ 

Undefined; 
Integer; 

so Floatingpoint; 



String; 
} DataType ; 



Undefined - data type not specified 
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Integer - data consisting of whole numbers 
Floatingpoint - double precision floating point number 
String - data expressed with characters 



5 Value 



10 
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Value is a union representing a variable data type. DataType defines the data's size and type. The 'C data structure 

follows: 

typedef union 
< 

int integer; 

double floatingpoint ; 

String string; 

} Value 
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integer - data consisting of whole numbers 
floatingpoint - floating point data 
string - data expressed with characters 

25 AxisID 

AxisID is an enumeration describing an individual axis. The 'C data structure follows: 

typedef enum 

30 

{ 

Xaxis; 
Yaxis; 

35 Zaxis; 

} AxisID 

Group 

40 

Group is a structure describing a group of axes. The 'C data structure follows: 

typedef struct 

45 { 

int id; 

int number Axes ; 

AxisID axes [ ] ; 
} Group 



so 



55 



id - Axes group id 

numberAxes - number of axes in group. 
Range 1 - NumberAxis max 
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9 axes - array of AxislD's 
State 

State is an enumeration of the current conditions of a device. The 'C* data structure follows: 

typedef enum 
{ 

Uninitialized; 
Calibrated; 
Stopped; 

at OrientPosition; 
} State 



Uninitialized - object has not been initialized. 
zo Calibrated - object has been calibrated. 

) Stopped - object is not moving 

OrientPosition - object has arrived at the orient position 
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Parameterlnfo 

Parameterlnfo is a structure describing information specific to a device. An example of a 'C data structure for a 
tool changer follows: 

typedef struct 
{ 

int toolID; 
int CarouselPosition; 
} Parameterlnfo 

toolID - integer representing the tool identification number 
Range: 1 - NumberTools max 

VelociNT\i>e 



Velocity Type is an enumeration of velocity representations. The 'C data structure follows: 



typedef enum 

{ 

Undefined; 
so XYZ; 

XYZAB; 
Spindle; 
} VelocityType 



XYZ - velocity for 3 axis machine 
XYZAB - velocity for 5 axis machine 
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Spindle - velocity of the spindle 
Velocity 

Velocity is a structure describing speed and direction. The 'C data structure follows: 

typedef struct 
{ 

VelocityType type; 
Value data; 
} Velocity 

type - indicates the type of velocity data in the structure 

data - velocity data; Units of (m/sec) for linear axis and (radian/sec) for rotary axis. 
Override 

Override represents a speed multiplier The 'C 1 data structure follows: 
typedef double Override; 

Override - representation of speed multiplier. Value of one (1) indicates 100 /•. 
Range: 0.1 - 2.0. 

Increment 

Increment represents a delta position. The 'C data structure follows: 
typedef double Increment; 

Increment - representation of a delta move. Units for increments are meters. 
Offset 

Offset is a structure describing Delta position. The *C data structure follows: 

typedef struct 
{ 

int count; 
^ double delta [ ] ; 
} Offset 

count - number of axes deltas described in structure, 
(range 0 -maxAxes) 

delta - array of axis deltas. Meters are used for linear axis, and radian is used for rotary axis. 
Feedrate 

Feedrate represents coordinated linear speed of the Cartesian axes. Feedrate uses units of (meters/second). The 
'C data structure follows: 

typedef double Feedrate; 

Linear 

Linear is a Qualifier used with 'Move- verb to describe a linear move. The 'C data structure follows: 
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typedef struct 
{ 

Position endPosition; 

5 

Attributes attributes [] ; 
} Linear 

w endPosition - represents the linear position at the end of the move 

attributes - attributes describe condition that affect the move. 'Until Limit Switch' is an example of an attribute. 

Tool 

is Tool is a Qualifier used to describe a tooL The , C data structure follows: 

typedef struct 
{ 

20 

} int toolID; 

} Tool 

25 toolID - Integer representing the tool identification number. 

Range: 1 - NumberTools max 

Gear 

30 Gear is a Qualifier used to describe gear ratio. The *C data structure follows: 

typedef struct 
{ 

35 

int gearlD; 
double gearRatio 
} Gear 

\40 

gc:*ilQ - integer representing the gear icentificati^n number 
qearRatio - floating point number representing the gear ratio 

Machine Class Message Formats 

45 

The Machine Class messages begin with verbs to describe the message requests. These verbs reflect the actions 
of the methods listed for the device objects described in the next section. In the list below, each verb is defined and 
possible message formats are shown after the definitions. Many Machine Class verbs stand alone to direct the actions 
of objects. For those verbs, no message formats are not listed. 

so 

Grab 

Requests ownership of a specific device. 
UnGrab 

Releases ownership of a specific device. 
55 Initialize 

Establishes default parameters necessary to operate a device. 

Unlnitialize 

Forces a re-initialization of a specific device (must initialize after this verb is used). 
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Get ^ . 

Retrieves the current information from a specific device. 

Get Description <name> Qualifier 
Get <Parameterlnfo> 

Update 

Establishes a specific operational parameter for a device. 

Update Description <name> Qualifier 

Update <Override> 

Update <Gear> 

Update <Feedrate> <value> 

Enable 

Enables special operation of a specific device. 
Enable <Power> 

Disable 

Disables special operation of a specific device. 
Disable <Power> 

Clamp 

Engages the clamp on an axis or spindle. 
UnClamp 

Disengages the clamp on an axis or spindle. 
Calibrate 

Establishes a reference point for a specific device. 

Run 

Begins continuous operation of a specific device. 

^^Marks the starting position of a sequential operation of a specific device. 
Cycle Description <cycle!D> 

Move 

Engages coordinated operation of a specific device 

Move Linear 
Move Velocity 
Move <lncrement> 

Dwell .„ 

Berlins null operation of a specific device for a specified time. 

Dwell FicatingPoint <time> 

Sl0P Ceases operation of a specific device in a manner that makes recovery possible. 
Cancel 

Ceases operation of a specific device immediately (recovery will not be possible). 
StSP Engages the predefined operation of a specific device in a forward direction. 
^^Engages the predefined operation of a specific device in a reverse direction. 
Machine Class Objects 

""° C=£=« ™Cf.,e »*™cK»». fcncioos. p,=c O.-.s. o, aCons thai «ha, * 
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to perform operations. The Machine Cl9Wbbjects with their methods are described in tflWCllowing sections. 
Flow Control Object 




In an alternate embodiment of the invention, the control system's Milling Machine Class's Flow Control object 
controls the communication between a CNC application and the Kernel's synchronous queue. This object allows a 
CNC application to set up a communications port to the Kernel and monitor the current state of the Kernel for the 
application. An application must get ownership of the Flow Control object to gain control of the Kernel's synchronous 
queue. The following methods are included in this object: 



Grab - 
UnGrab - 
Initialize * 
Get <State> - 
Enable <Power> - 
Disable <Power> 
Run - 
Stop - 
Cancel - 
Step - 



requests ownership of the Kernel's synchronous queue, 
releases ownership of the Kernel's synchronous queue. 

establishes default parameters necessary to operate the Kernel's synchronous queue. 

gets the current active state of the Kernel's synchronous queue. 

enables power for the Kernel's synchronous queue. 

disables power for the Kernel's synchronous queue. 

directs the Kernel to process synchronous requests continuously. 

directs the Kernel to stop processing requests from the synchronous queue. 

directs the Kernel to stop all activity immediately and flush the queue. 

directs the Kernel to process a single request in the synchronous queue. 



Push-button Console Object 

The Milling Machine Class's Push-button Console object allows an application to initialize and reserve all necessary 
buttons and lights on the console. In this way, the operator can press buttons to control power, start a cycle, hold the 
motion of the machine, and interrupt an operation while an application monitors these actions. When an operator 
presses a button, a message is sent to the application controlling that button. If the buttons are not enabled by an 
application, they are ignored by the Logic Controller. 

The following methods are included in this object: 

Initialize - establishes default parameters necessary to operate the push-button console. 

Grab - requests ownership of the push-button console. 

UnGrab - releases ownership of the push-button console. 

Get - requests specified information from system components. 

Enable - enables remote operation on the push-button console. 

Disable - disables remote operation of the push-button console. 

Update - establishes a specific operational parameter for the push-button console. 

Jog Pendant Object 

Ti :^ Milling Machine Class's Jog Pendant object allows an application to initiel./e and reserve all necessary buttons 
and lights on the jog pendant. When an operator presses a button, the Kernel can generate a Move message imme- 
diately after receiving an Enable message from an application. If the buttons are not enabled by an application, they 
are ignored by the Kernel. 

The following methods are included in this object: 



Initialize - 
Grab - 
UnGrab - 
Get - 
Enable - 
Disable - 

Axis Object 



establishes default parameters necessary to operate the jog pendant. 

requests ownership of the jog pendant. 

releases ownership of the jog pendant. 

requests specified information from system components. 

enables remote operation on the jog pendant. 

disables remote operation of the jog pendant. 



The Milling Machine Class's Axis object allows an application to control an individual axis or joint. The following 
methods are included in this object: 
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establishes default parameters necessary to operate an axis, 
requests ownership of an axis, 
releases ownership of an axis, 
gets the current active state of an axis, 
returns current parameters, 
engages the clamp on an axis, 
releases the clamp on an axis, 
establishes a reference point for an axis, 
moves the axis at a specified velocity, 
moves the axis a specified distance, 
halts axis motion. 



Initialize - 
Grab - 
UnGrab - 
Get <State> - 
Get <Parameterlnfo> - 
Clamp - 

UnClamp - 

Calibrate - 

Move <Velocity> - 

Move <lncrement> - 

Stop - 

Axis Grouo Object 

establishes default parameters necessary to operate the ax.s group, 
requests ownership of the axis group, 
releases ownership of the axis group, 
gets the current active state of the axis group. 

SSS - * - —P us, 9 poinMo-pOn, «. 

pauses in motion defined by time in tenths of seconds, 
(axes) identifies which axes belong to this group, 
indicates the feedrate override factor, 
(value) indicates the speed applied to a given Ax.s Group, 
indicates the offset used for Part Zero and other general offsets. 



Initialize - 
Grab - 
UnGrab - 
Get <State> - 
Get <Parameterlnfo> 
Move <Linear> - 

Move <Joint> - 
Dwell - 

Update <Group> - 
Update <Override> - 
Update <Feedrate> - 
Update <Offsets> - 



The Axis Group object has these additional methods: 



enables power to the axis group 
disables power to the axis group, 
stops the specified axes. 



Enable<Power> - 
Disable <Power> ■ 
Stop - 

Spinoie Object 

establishes default parameters necessary to operate the spindle, 
forces a re-initialization of the spindle, 
requests ownership of the spindle, 
releases ownership of the spindle, 
gets the current active state of the spindle. 

£ 2 E£p— *— . an, 3, « PPM o, 

the move. 

overrides the speed by a specified factor, 
initiates a remote change of the spindle's gear speeds, 
holds the tool in the spindle, 
releases a tool from the spindle. 



45 initialize - 

Unlnitialize - 

Grab - 

UnGrab - 

Get <State> - 
so Get <Parameterlnfo> 

Run - 

Update <Override> - 
Update <Gear> - 
ss Clamp - 
Unclamp - 



The Spindle object has these additional methods: 
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Enable - enables remote operation of the spindle's manual push-button. 
Disable - disables remote operation of the spindle's manual push-button. 
Stop - stops motion of the spindle. 



Tool Changer Object 

The highly detailed Tool Changer object describes all possible functions of a tool changer. This object has access 
to the data indicating the number of tools in the changer, the current tool in the spindle, and the carousel position. The 
tool changer grabs ownership of the required resources such as the spindle and axes. The tool changer uses the 
storage slot number rather than the tool number for positioning. The tool number and related data are included in the 
Tool database. This object contains the following methods: 



20 

\ 



Initialize - 
Unlnitialize - 
Grab - 
UnGrab - 
Get <State> - 
Get <Parameterinfo> 
Update <Tool>- 
Enable - 
Disable - 
Calibrate - 



establishes default parameters necessary to operate the tool changer. 

forces a re-initialization of the tool changer. 

requests ownership of the tool changer. 

releases ownership of the tool changer. 

gets the current active state of the tool changer.. 

gets current information parameters for the tool changer. 

sets the storage slot number for a tool in the spindle. 

enables remote operation on the tool changer. 

disables remote operation of the tool changer. 

sets the indexer position. 



This tool changer object also contains these methods: 

Cycle - marks the starting position of a sequential operation of the tool changer. 
Stop - halts tool changer motion. 

Step - moves the tool changer one logical step at a time. 



so Coolant Object 

The Coolant object describes all possible functions of the coolant mechanism. This coolant object contains the 
following methods: 

35 Grab - requests ownership of the coolant device. 

UnGrab - releases ownership of the coolant device. 

Get <State> - gets the current active state of the coolant device. 

Stop - indicates when to stop the coolant. 

Run - begins continuous application of coolant and identity the type of coolant (mist, flood, or both). 

Enable - enables automatic clearance plane detection and automatic shut-oft. 

Dinablfe - disables automatic clearance plane detection and automatic shut-off. 



Lube Object 

J 5 The Lube object describes all possible functions of the lubrication mechanism. This lube object contains the fol- 

lowing methods: 

Grab - requests ownership of the lubrication device. 

UnGrab - releases ownership of the lubrication device. 

50 Get <State> - gets the current active state of lubrication device. 

Stop - indicates when to stop the lubrication. 

Run - begins continuous application of lubrication. 



Kernel-Machine Class Communication Example 

55 

The following communication example demonstrates data moving through the Machine Class to the Kernel com- 
ponents. In this example, the CNC application is operating a spindle using the following steps: 
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1 . Application grabs ownership oJ the Spindle. It receives an 'OK' or a ™rved' response. 

2 Application requests SpindleRun. 

3. Machine Class sends these requests to the Motion Controller: 

. Update <Gear> (directs Logic Controller to activate sequence) 

• Wait until LCflag (directs MC to wait for the LC flag) 

• Move Velocity <rpm> (directs MC to apply voltage to the spindle axis) 

. Update <Flag> SpindleAtSpeed (directs LC to report when up to speed) 

• Wait until LCflag (directs MC to wait for LC flag before continuing) 

4 The Motion Controller returns 'OK' or 'Conflict' responses. 

5. The Motion Controller sends a SpindleGear request to Logic Controller and warts for LCflag. 

6. LC executes spindle enable and gear change logic: 

• spindleOrient = Off 

• spindleEnable = On 

• spindleOn = On 

• select gear speed based on RPM 

7. LC sends request to MC to creep spindle axis. 

8. MC sends 'atCreep' message to LC. . 4 . n . ee 

9. C selects gear. If an error occurs an error message is sent to the Exception reporter and the Mach.ne Class 

flushes the queue. 

10 LC sets LCflag to satisfy first MC Wait (indicates that it is OK to start axis). 

11 MC begins spinning the Spindle axis based on Move parameters. If an error occurs, send an error message 
to Exception Reporter, and the Machine Class flushes queue. 

12 MC gives SpindleAtSpeed request to LC. . 

13. LC waits for SpindleAtSpeed input or time-out. If an error occurs, send error message to Exception Reporter, 

and the Machine Class flushes queue. 

14 LC sets LCflag to satisfy second MC Wait (indicates sequence is complete). 

15 LC sends Completion response to Application (if requested by Application). 
16. Machine Class sets DalState = SpindleRunning (if requested by Application). 

Customizing a Machine Class 

The open systems design of the control system of the present invention permits modification of the Machine Class 
to handle machines that have not been used by the control manufacturer. This is possible because the devices are 
l^enLX defined from the relationships between the devices. The Kernel's Logic Controller and the apphcat.ons 
Kr-nriie the a^ual device interdependencies during operation. 

A sister user may add features to a device definition and/or modify the characteristics of the dev.o w.thout re.ng 
forced to change other devices. This allows the customer to dovelop an implementation of the system ^tom.zed <or 

3 SP TheMachine Class's object^riented design allows software engineers customizing the Machine Class to quickly 
create new Machine Class objects by inheriting from existing Machine Class objects and then ^^9^^™ 
of the advanced programming features of C ++ , a software engineer need not alter the source code o the control system 
to the objects in order to modify them. The new objects then inherit the common data charactenst.es from the paren 
object This teature allows software engineers to build on existing design and code by creafng more spec.fic ob,ects 
from the easily reused code in the existing Machine Class objects. „ aatttfi 
As with data characteristics, methods can also be inherited from the paren, object when a new object create* 
Of course, the new object may use the method or create a different version of it. Methods send messages tc , perform 
operations. This isolates dependency on a particular data structure thus permitting new features to be added wrthout 
changing the arrangement of the original objects. 

Kernel 

The Kern I of the control system provides mechanisms for coordinating motion axes with discrete input/output (I/ 
CO cIntro?Th ls genera, controller can be used in a variety of machining applications. The CNC apphcat.ons commu- 
S"e wUhlh^ Kerne, components, the Logic Controller (LC) and the Motion Controller (MC). through the Mach.ne 
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Class. 

Since the control system's software uses object-oriented design and programming techniqu s, the software com- 
ponents are created from data and functions organized into objects. The Logic Controller and Motion Controller com- 
ponents communicate with each other and with the CNC applications through special objects called messages. These 
messages use a common message structure, and both have a common message interface. Each component has an 
asynchronous queue and a synchronous queue. These queues function in the same manner in both controllers. 

Messages may be synchronous or asynchronous depending on the requirements of the application. The synchro- 
nous messages are ordered and. therefore, dependent on the execution of previous messages in the queue. The 
asynchronous messages are independent of previous messages so that they can be executed immediately 

Kernel Message 

The system messages provide two-way communication between the applications and the Kernel components. 
These messages have the following capabilities: 

Single commands 

Initialization parameters and configuration sent through the messages 
Synchronous messages are queued 
Asynchronous messages are executed immediately 

There are different categories of messages: 

Flow control 

Parameters 

Diagnostics 

Requests 

Data 

Error 

Message Structure 

The messages of the control system of the present invention have a standard grammar using command verbs with 
possible qualifiers and variable attributes. There are three types of qualifiers: 

Structure - defines a type of variables. 

Enumeration - a list of integer values allowing association of constant values with qualifier names. 

Union - a variable that may hold (at different times) objects of different types and sizes. It is used to manip- 

ulate different kinds of data in a single storage area without embedding any machine-dependent 
information in the program. 

Ir. '.he list o messages presented below, required data elements begin with a capita: letter, and optional elements 
use no capitals. Messages used by the Kernel have this basic structure: 

Verb Qualifiers 

A verb describes the message request. 

Qualifiers are data structure names followed by the data structure elements. These qualifiers can be composed of 
other qualifiers (i.e.. dynamic data structures). Verbs act on the qualifiers. 
The verbs used by the Kernel components are - 



Run - is used to control the execution of the synchronous buffer (MC and LC). 

StopRun - is used to control the execution of the synchronous buffer (MC and LC). 

Move - directs the Motion Controller to move along a linear path or move at fixed velocity. 

Wait - tells the MC or the LC to not execute any messages after the Wait message until a StopWarting message 
is sent. 

StopWait - tells the MC or the LC to begin executing messages again. 

Get - tells the MC or LC to send information to an application. 

Update - tells the MC or LC that an application wants to change the value of a parameter. 



39 



EP 0 717 866 B1 

Flush . tens the Motion Control to da.ete al. of the messages in its synchronous queue. 

Kernel Qualifiers 

me d« scores to, a.l messages ana gloM dale used by Kernel- 

String 

,o String is a structure describing a Section of ASCI characters. The V data structure .ol.ows: 

typedef struct 
{ 

is int length; 

char characters [ ] ; 

} string; 

lenqth - is the number of characters in the string, 
characters - is an array of letters, numbers, and/or symbols. 

Name 

typedef String Name 
Description 

30 o~**» is a s»uc,u,e used . denae me M chafes o, ,he su*,c, o, me message. TKe C d»,a 

structure follows: 

typedef String Description 

35 Value 



folic 



follows 

40 



typedef union 
{ 

int integer ; 

45 double floatingpoint; 

String string; 
> Value 

50 

integer - is the data consisting of whole numbers. 

floatingpoint - floating point data. 

string - is the data expressed with characters. 

55 PositionType 

PositionType is an enumeration of Position representations. The tr data structure foHows: 
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typedef enum 
{ 

. Undefined; 

XYZ; 

XYZAB; 

ZS; 

Spindle; 
} PositionType 

:s XYZ - position for 3 axis machine. 

XYZAB - position for 5 axis machine. 
ZS - position of the Z axis and spindle. 
Spindle - position of the spindle. 

20 XYZ 
i 

XYZ is a structure describing a position for the X and Y and Z axes. The *C l data structure follows: 

25 typedef struct 

{ 

double x; 
double y; 

30 

double z ; 
} XYZ; 

35 x * position for the X axis. 

Range: X min - X^ (units: meters) 
y - position for the Y axis. 

Range: Y min - Y max (units: meters) 
z - position for the Z axis. 
J Ra-.ge: Z min - Z max (units: meters) 

XYZAB 

XYZAB is a structure describing a position for the X and Y and Z and A and B axes. Linear position is expressed 
45 in meters. Rotary position is expressed in radians. The 'C data structure follows: 



so 



ss 
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AttributeType 

AttributeType is an enumeration of attributes. The 'C data structure follows: 

typedef enum 
{ 

undefined 
Limit Switch 
Probe 
Overrides 
MotionHold 
Absolute 
Incremental 
Deceleration 
Concurrent; 
} AttributeType 

indicates that the move is terminated on either make or break of limit switch, 
indicates that the move is terminated on either make or break of probe, 
enables or disables override for move, 
enables or disables override for move, 
position is described in absolute coordinates, 
position is described in incremental coordinates, 
deceleration attribute. 

this move can be concurrently executed with another move. 



LimitSwitch - 
Probe - 
Override - 
MotionHold - 
Absolute - 
incremental - 
Deceleration - 
Concurrent - 



Linear 



Linear is a qualifier used with the Move verb to describe a linear move. The 'C data structure follows: 

typedef struct 
{ 

Position position; 
Attributes attributes; 
} Position 



position - indicates the endpoint of the linear move, 
data - attribute modifying the motion description. 

VelocitvType 

VelocityType is an enumeration of velocity representations. The 'C data structure follows: 
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m 

type - indicates the typ of position ^^Pn the structure. 

data - position data; meters are used for a linear axis and for a rotary axis. 

Contact 

Contact is an enumeration types of physical contact for attributes. For example, a probe attribute is a move until 
a probe makes contact or break contact. The 'C data structure follows: 

typedef enum 
{ 

Undefined; 
Make; 
Break; 
} Contact 

Make - contact is made. 
Break - contact is broken. 

EnableDisable 

EnableDisable is an enumeration describing if a attribute is enabled For example, the Feed rate override is enabled 
or disabled. The *C' data structure follows: 

typedef enum 
{ 

Undefined; 
Enable ; 
Disable; 
} EnableDisable 

Enable - turn on attribute. 
Disable. - turn off attribute. 

Term ing* i onTvpe 

TerminationType is an enumeration describing the ending condition of a move. The *C data structure follows: 

typedef enum 
{ 

Undefined; 
PrecisionEndPoint ; 
NoDeceleration ; 
} DecelerationType 

PrecisionEndpoint - end point of line must be reached with in in-position toleranc . 
NoDeceleration - Move is part of continuous contour. End point is not important. 
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AttributeType 

AttributeType is an enumeration of attributes. The 'C data structure follows: 

typedef enum 
{ 

undefined 
Limit Switch 
Probe 
Overrides 
MotionHold 
Absolute 
Incremental 
Deceleration 
Concurrent ; 
} AttributeType 



LimitSwitch - 
Probe - 
Override - 
MotionHold - 
Absolute - 
Incremental - 
Deceleration ■ 
Concurrent - 



indicates that the move is terminated on either make or break of limit switch. 

indicates that the move is terminated on either make or break of probe. 

enables or disables override for move. 

enables or disables override for move. 

position is described in absolute coordinates. 

position is described in incremental coordinates. 

deceleration attribute. 

this move can be concurrently executed with another move. 



Linear 



Linear is a qualifier used with the Move verb to describe a linear move. The 'C data structure follows: 



typedef struct 
{ 

Position position; 
Attributes attributes ; 
} Position 



position 
data - 



indicates the endpoint of the linear move, 
attribute modifying the motion description. 



Velocity Type 

VelocityType is an enumeration of velocity representations. The 'C data structure follows: 
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typedef enum 
{ 

5 Undefined; 

XYZ; 
XYZAB; 
Spindle ; 

w 

} VelocityType 

1$ XYZ - velocity for 3 axis machine. 

XYZAB - velocity for 5 axis machine. 
Spindle - velocity of the spindle. 

Velocity 

20 

\ Velocity is a structure describing a position. The 'C data structure follows: 



typedef struct: 

{ 

VelocityType type; 
Value data; 
30 } Position 

type - indicates the type of velocity data in the structure. 

data - velocity data; Units of (m/sec) for linear axis and (radian/sec) for rotary axis. 
35 Velocity Move 

VelocityMove is a qualifier used with the Move verb to describe a constant velocity move. The 'C data structure 
follows: 

y° 

7 typedef struct 

{ 

Velocity velocity; 

45 

Attributes attributes; 
} VelocityMove 

velocity - indicates the rate and the reference frame of the move. 

50 attributes - attribute modifying the motion description. 

RunAttribute 

RunAttribute is an enumeration of Run message attributes. The 'C data structure follows: 

55 
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typedef enuro 



{ 



Undefined; 
SingleCycle; 



70 
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\0 



25 



30 



35 



SingleCycle - 
Immediate - 
EndofCycte - 
Motion Hold - 

ErrorCode 



Immediate; 
EndOf Cycle; 
MotionHold; 
} RunAt tribute 

requests that the motion control stop after the end of each cycle, 
requests that the motion command be executed immediately, 
marker for separating moves in a cycle, 
indicates a motion hold condition. 



ErrorCode is an enumeration of types of error codes. The 'C* data structure follows: 

typedef enum 
{ 

NoSeverity; 
Information; 
Warning; 
Fatal; 
} ErrorCode 



> 
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NoSeverity - 
Information - 
Warning - 
Fatal - 

Motion Controller 



error of uncategorized severity. 

error message providing information only (no action required), 
e ror indicating application is having difficulty completing the task, 
erw indicating application is not able to complete current task. 



The Kernel's Motion Controller perlorms mufti-axis interpolation generating target points for the servo hardware. 
The Motion Controller supports high speed spindles (up to 60,000 RPM), rigid tapping, encoder jog, and touch probing. 
An exemplary motion controller has these features: 

Five (5) coordinated axes plus one (1) spindle 

* Programmable interpolation rate - 5 milliseconds to 20 milliseconds 

* Provides status information for - 

* position (command and actual) 

* velocity 

* following error 

Leadscrew and backlash compensation using linearly interpolated tables 

* Leadscrew compensation corrects for mechanical error up to 200 times per second 
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5 millisecond block transfer rate resutti 



more detailed information being processei 



;er 



* Non-linear control for circle compensation 

Acceleration control regulates velocity, allowing tighter coordination between more than one axis while minimizing 
mechanical wear on the machine 

* Coordinated interpolation with the spindle 
Programmable calibration and referencing sequence 

Enhanced Servo Algorithm interfaces with the motion controller board to monitor machine position 10.000 times 
per second 

Configuration Parameters of the Motion Controller 

The Motion Controller configuration parameters define the travel limits, PID gain parameters, kinematics, and 
additional miscellaneous parameters. 



This parameter establishes the valid travel limits. They can be negative to positive or positive to negative along 
the X, Y. and 2 axes. 

PID Gain Parameters 



proportional (P) 
integral (I) 
derivative (D) 
integral limit 
velocity feed forward 

The parameter values are downloaded to the appropriate hardware for controlling the axis. Then, the modified PID 
algorithm with velocity feedforward residing on the hardware controls each axis. 
The Application Tool Kit may be utilized to set and adjust the parameters. 

Programmable Kinematics 

The user may specify the relationships between axes to support a variety of axis configurations. The forward 
kinematics determine the position and the orientation of the end-effector given the joint angles. The inverse kinematics 
determine the joint angle given the position and orientation of the end-effector. The possible kinematics parameters are - 

X position = X G J 0 + X, J A + X>2^2 + ^3^3 + ^ 4 J 4 
Y position = Y 0 J 0 ■:- Y, J, + Y^ -» Y3J3 + Y 4 J 4 
Z position = ZqJ 0 + Z 1 J, + Z2J2 + 2 3 J 3 + Z 4 J 4 
A position = AqJq + A 1 J, + A2J2 + A 3 J 3 + A 4 J 4 
B position = B 0 J 0 + J 1 + B2J2 + B 3 J 3 + B 4 J 4 

Miscellaneous Motion Control Parameters 

Some additional parameters that can be set by the Motion Controller are - 

DAC (digital analog converter) balance parameter 

* Maximum acceleration 

* Axis sense 
Axis resolution 

* Maximum rotary RPM 

Limit switch to marker pulse (index pulse) 

* Lead screw compensation table 



Travel Limits 



The gain parameters are used for closed loop control of each axis (x to b). These parameters are - 
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Motion Controller Messaqes 

The messages of the control system are objects, such as C++ objects. Each message object is transmitted in 
binary form to the receiving application's mailbox and then rebuilt into an object. This section describes the Mot.on 
Controller message verbs: 
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Run 


Update 


Move 


StopRun 


Wait 


Flush 


Get 


StopWait 



Modals establish a condition that persists until another modal changes it. The Motion Controller modals are ■ 



OverrideEnable 
MotionHoldEnable 
IncrementalEnable 
DecelType 



These modals can also be used as one-shot modals within messages to temporarily set a modal value during the 
^ execution of the message and restore the mode prior to execution. The concurrent modal, used only as a one-shot 
J modal, tells the system that a message is linked to the next message and that both must be executed as one. This 
could span more than one pair of messages. 



Run 



The Run messages are used with the StopRun messages to control the execution of the synchronous buffer. The 
Run message asks the Motion Controller to start executing messages from its queue. 



Run <Qualifier> 

Run RunAttribute <attribute> 



The Run RunAttribute directs the Motion Controller to begin execution of the messages in the synchronous buffer. 

c attribute> none . 

SingleCycle The Run SingteCycle directs the Motion Controller to execute messages in the synchronous buffer a 
block at a time. Block are delimited by SingleCycleHeader messages. 

Expected Responses 

) |f the Moton Contro |ier is able to begin execution of messages from the synchronous buffer, ; responds with a 
- Running Message. If the Motion Controller is not able to execute the messages from the synchronous buffer, it responds 
with a NotRunning message. The expected responses for any of the run commands are - 



Running <Qualifier> 

NotRunning <Qualifier> Description 

<errordescription> 

StopRun 

The StopRun message is sent to the Motion Controller to halt the execution of the message in the synchronous 
buffer. The motion can halt execution of message immediately (with controlled deceleration of mot.on) or at a block 
boundary. Block boundaries are delimited by Cycle Headers. 

StopRun RunAttribute <attribute> 
This StopRun message asks the Motion Controller to stop execution of the synchronous buffer. 

StopRun RunAttribute <attribute> 

attribute>immediate deceleration motion at the maximum acceleration rate. 
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SingleCycle - 




►xceeding maximum ac- 



Expected Responses 

When the Motion Controller receives a StopRun message, it harts execution of the message in its synchronous 
butter and responds with a StoppedRunning message (format below). 
StoppedRunning <Qualifier> 



The Move message in the Motion Controller has two qualifiers: Linear and Velocity. The Move message uses this 
basic structure: 

Move <Qualifier> <attributes> 



The Move Linear message directs the Motion Controller to move along a linear path. The path is defined by the 
position specified in the message from the end point of the previous move. The message structure is - 
Move Linear <Position> <attribute> 

Elements 

<Position> XY2 



find index pulse 
override <enable!disable> 
motion hold <enable!disable> 
probe <enableldisable> 
obsolute! incremental 
decel <type> 
concurrent 



Sample Messages: 

Move Linear XYZ 10 11.1 12.0 untilSwitch break 
Move Linear XYZ* 10.5 20.0 '00.1 findindexPulse 
Expected Responses 
NotMoving <Qualifier> <attributes> 

Description <errordescription> 

Moving <Qualifier> <attributes> 
Move VelocityMove 

The VelocityMove message asks the Motion Controller to move its axes at a specified velocity. 
Move VelocityMove <Velocity> 

<attribute> 

Elements 

<Velocity> XYZ 

XYZAB 
XYZABS 



Move 



Move Linear 



<attribute> 



XYZAB 

ZS 

S 

until switch <breaklmake> 
until probe <break!make> 
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S 

<attribute> until switch 



<break!make> 

5 

until probe <break!make> 
find index pulse 
override <enableldisable> 
motion hold <enableidisable> 
to probe <enableldisable> 

decel <type> 
concurrent 



Expected Responses 

15 

Moving Velocity Move <Velocity> <attribute> 
NotMoving VelocityMove <Velocity> <attribute> 
Description <errordescription> 



i 20 Wait 

A Wait message is usually sent to the Motion Controller's synchronous queue. The message asks the controller 
to not execute past this message until a StopWaiting message is sent. 



25 Wait Message 

Wait message <id> 
Sample Messages: 

Wait message 1152 
30 Expected Responses 

Waiting message <id> 

NotWait message <id> Description 



35 <errorDescription> 



StopWaiting Message 

The StopWaiting messape is srnt to the Motion Controller to cancel a Wait message. 
40 StopWaiting me&sage <id> 

Expected Response 
StopoedWaiting message <id> 
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Update 



An Update message is sent to the Motion Controller when an application wishes to change the value o. a parameter. 



<FieldName> 


<Type> 


Description 


Feedrate 

Override 

OverrideEnable 

MotionHoldEnable 

Probe 

ZeroPosition 


floatingpoint 

floatingpoint 

EnableDisable 

EnableDisable 

EnableDisable 

Position 


Sets the value of the feedrate to be used by the following motion blocks 

Set the value for the feedrate override. 

Enable or disables the effect of the feedrate override 

Enable or disables the effect of MotionHold 

Enable or disables the Probelnput 

Set the Zero for the coordinate system 
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(continued) 



<FieldName> 


<Type> 


Description 


Header 


Header 


The Update Header message allow the applications sending the messages 
to the Motion Controller to embed User Header information into the Queue. 



Expected Responses 



Updated Name <FieldName> Data Type <Type> Value <Data> 
NotUpdated Name <FieldName> DataType <Type> 
Value <Data> Description <errorDescription> 



Get 

A Get message is sent to the Motion Controller when an application wishes to access information from the Motion 
Controller. The message allows the application to find and read motion control parameters and state variable and 
motion registers. These registers are - 



Current position 
^ Index position 

j Probe position 

Commanded position 

Velocity 
25 Following Error 

Get Name 



Get Name <FieldName> DataType <Type> 



<FieldName> 


<Type> 


Description 


Probe Position 


Position 


Holds the position of the axes at the last probe contact. 


Index Position 


Position 


Holds the position of the axes at the last index pulse. 


Current Position 


Position 


Gets current position of the axis 


Commanded Position 


Position 


Gets the commanded position of the axis 


Following Error 


Position 


Gets the following error for the axis 


Velocity 


Velocity 


Gets the velocity of the axis 



r 



<F;eldName> 


<Type> 


Description 


Override 
OverrideEnable 
MotionHoldEnable 
Probe 


floatingpoint 
EnableDisable 
EnableDisable 
EnableDisable 


Gets the value for the feedrate override. 
Indicates if Override is enabled. 
Indicates if MotionHold is enabled. 
Indicates if Probe is enabled. 



Expected Responses 

so Got Name <FieldName> DataType <Type> Value <Data> 

NotGotten Name <FieldName> DataType <Type> 

Flush 

55 The Flush message is sent to the Motion Controller when a application wants the Motion Controller to delete all 

of the messages from its synchronous message queue. 

Flush <ProcessName> 
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10 



Expected Responses 

Flush d 
NotFlushed 

Motion Controller Notes 

The following describes some of the control options which may be desired in the Motion Controller according to 

the present invention. 

Calibration Sequence 

The Motion Controller contains a programmable sequence of primitives which include: 

75 Move until not limit switch (oft) 

Move until index pulse 
Move to index pulse 
Update position 
Update position offset 

> 

t Probing 

The Motion Controller's probing configuration includes: 

25 Move to position on probe head 

Move until not probe (off) 

Logic Controller 

ao The Kernel's Logic Controller (LC) is an engine that executes logic programs by scanning inputs, executing pro- 

grams, and then writing outputs to operate the machine tool. The LC has these features: 

Executes ladder logic programs 
Executes GRAFCET programs 
35 Supports local or bussed I/O including CANbus and Pamux 

Programmable scan rate down to 20 milliseconds and dependent on the size of the program 
Programmable off-line or on-line 
Program using existing off-the-shelf products 
v Supports on-line LC monitoring 

J 40 Supports on-line I/O monitoring 

^ On-line debugging 

Simulation 
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SO 



Communicates through messages . f . ffTia , 

Supplies a window-based translator to convert common, logic control f.le formats into the LC f.le format 

Optional embedded Logic Controller in hardware with programmable scans down to 1 millisecond 
Logic Controller Messages 

The messages of the logic control are objects, such as C ++ objects. Each message object is transmitted in binary 
form to trTS^applcSion-. mailbox and then rebuitt into an object. Three types of message can be sent to the 

Logic Controller: 

55 Synchronous queue control (Run, Stop) 

Send data (Update) 
Access data (Get) 
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When the Logic Controller receives us^J^ned messages, it stores them in its data laf^^ogic must be added to 
the ladder program to evaluate and execute the message. An example of a user-defined message appears in the 
following table: 



Type 


Definition 


Data 


1 


Tool changer 


1 - automatic, tool number 






2 - retract 






3 - extend 


2 


Coolant on/off 


0 - off, 1 - on 


3 


Enable servo power 





Run 

The Run messages are used with the StopRun messages to control the execution of synchronous buffer. The Run 
message asks the Logic Controller to start executing messages from its queue. 
Run <Gualifier> 
Run RunAttribute <attribute> 
The Run RunAttribute directs the Logic Controller to begin execution of the messages in the synchronous buffer. 

attribute> none 

SingleCycle The Run SingleCycle directs the Logic Controller to execute messages in the synchronous buffer a 
block at a time. Block are delimited by SingleCycleHeader messages. 

Expected Responses 

If the Logic Controller is able to begin execution of messages from the synchronous buffer, it responds with a 
Running Message. If the Logic Controller is not able to execute the messages from the synchronous buffer, it responds 
with a NotRunning message. The expected responses for any of the Run messages are - 

Running <Qualifier> 

NotRunning <Qualifier> Description 

<errordescription> 

StopRun 

The StopRun message is sent to the Logic Controller to halt the execution of the message in the synchronous 
buffer. The motion can halt execution of message immediately (with controlled deceleration of motion) or at a block 
boundary. Block boundaries are delimited by Cycle Headers. 

SiopRui! RunAttribute <attribute> 

This StopRun message asks the Logic Controller to stop execution ot the synchronous b'jffer. It uses this 
format - 

StopRun RunAttribute <attribute> 

<attribute> immediate • deceleration motion at the maximum acceleration rate. 

SingleCycle - stop execution at the first block end (SingleCycleHeader) with out exceeding maxi- 
mum acceleration. 

Expected Responses 

When the Logic Controller receives a StopRun message, it halts execution of the message in its synchronous 
buffer and responds with a StoppedRunning message. 
StoppedRunning <Qualifier> 

Wait 

A Wait message is usually sent to the Motion Controller in its synchronous queue. It asks the Motion Controller to 
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not execute past this message until a StopWaiting message is sent. 
Wait Message 

Wait message <id> 

Expected Responses 

Waiting message <id> 

NotWait message <id> Description <errordescription> 

Sample Messages 
Wait message 1152 

StopWait Message 

The StopWaiting message is sent to the Motion Controller to cancel a Wait message. 

StopWaiting message <id> 
Expected Responses 

StoppedWaiting message <id> 

Update 

Update messages are sent to the Logic Controller by Application program to provide information to the ladder 
program. The message may update a flag in the Logic Controller data table, send a generic message, or prov.de a 
new ladder program to the Logic Controller. 

Update <Qualifier> 

Expected ^^J^^ pfocess Update messages at the beginning of its scan. It responds with a Updated 
message to indicate that the Update message was successfully executed, tf the Logic Controller is not able to 
perform the Update, a NotUpdated Message is returned. 
Updated <Qualifier> 

NotUpdated <Qualifier> Description <errorDescription> 
Flag Access Logic Controller data table by Names 
FlagID Access Logic Controller data table by flag id 
L3M?n Generic Logic Controller Message 
Program Loads sections of the Logic control message 
Update Flag 

The Update Flag message is used to change a value in the Logic Controller data table. These messages are 
interpreted at the beginning of each LC program scan. The Flag can be referenced through a Name or an ID. 

Update Flag Name <FlagName> DataType <Type> Value <FlagValue> 
Update Flag ID <FlaglD> DataType <Type> Value <FlagVaiue> 
Update LCmsg 

The Update LCmsg is used to send a generic message to the Logic Controller. 
Th actual message is interpreted by the ladder program. 
Update LCmsg <msgType> Size <MsgSize> 
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Value <msg> 

Update Program 

An application uses the Update Program message to down load ladder program messages to the Logic 
5 Controller. The Program is down loaded by breaking it up into segments and sending the segments to the Logic Con- 
troller. The 'SequenceNumber* is used to make sure the program segments are received in order. 

Update Program ProgramID <Progld> 
Sequence <SeqNumber> String 
10 <progSegment> 



Get 

An application sends a Get message to the Logic Controller when it wishes to access information from the Logic 
is Controller's data table. 

Get Flag Name <FlagName> DataType <Type> 
Get Flag ID <FlaglD> DataType <Type> 
Expected Response 

20 The Logic Controller responses to the Get messages at the end of each of the ladder program scans. 

) The Got message is used to return the value of the requested flag. The NotGotten message indicates the requested 

i flag was not defined. 

Got Flag ID <FlaglD> DataType <Type> Value <FlagValue> 
NotGotten Flag ID <FlaglD> DataType <Type> 
25 Description <errorDescription> 



Ladder Logic Programming 

The ladder logic programming environment gives the OEM off-line tools and a controller resident monitor to cus- 
30 tomize the LC. There are three components of the ladder logic programming environment: 



Ladder Logic Programming Tool (off-line) 

Ladder Logic Debug Tool (remotely hosted, serially linked) 

Logic Monitoring Tool (controller resident) 

The programming environment provides version control for the logic programs and back-up to any point in the changes. 
This feature also allows the OEM to branch off at a selected point and start new development paths for new machine 
strategies. 



'Y° Programming lool 
i 

An OEM can create and change ladder logic programs using familiar notaiion and concepts provided ir. the Ladder 
Logic Programming Tool. This tool gives the developer an easy-to-use off-line, graphical method for creating, editing, 
running, testing, and downloading logic control programs for the controller. With the tool the engineer can design control 
45 programs from initial concept to final operation using top-down design procedures. The following are programming 
tool's features: 



Supports programming in ladder logic: 

Coils and Contacts 

Virtual Coils and Contacts 

Timers 

Counters 

Branches 

Function Blocks for math (add, subtract, multiply, divide, trig.) 
Function Blocks for interface toCNC 

Output in •ANSI-C source code form for cross-compile to target coprocessor board 
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Outputs a symbol table that may be read by other programs - useful for parameterization and creation of shared 
data tables 

Supports programming in sequential function charts (GRAFCET SFCs) 
Produces hard copies of program and data documentation 

Supports programming in timing diagram form Version control allows the integrator to make incremental changes 
with an audit trail 



[.adder Logic Debugging Tool 

10 The on-line debugging tool runs on a Windows workstation with a serial (RS232) link to the controller. This tool 

provides the following features: 

* Graphic illustration of the contacts and coils in the ladder program as they energize and de-energize 

* Ability to monitor and set values in the data table including counter and timer accumulators 
is * Display of the GRAFCETsteps and transitions as they activate and deactivate 

Ability to command the Logic Controller engine to execute one scan at a time 



Logic Monitoring Tool 

The real-time Logic Monitoring Tool gives the integrator a way to observe the states, inputs, and outputs of th< 
machinery during cycling on the machine tool itself. The software allows the integrator to watch for timing problems ii 
I/O, facilities debugging of logic sequences, and helps with machine wiring or switch adjustments. 

The features of the Logic Monitoring Tool are listed below: 



25 * Incorporated into the CNC executive software system 
Accessible though the CNC's platform diagnostic mode 

* Displays states of inputs and outputs in real-time 

* Allows the integrator to force the states of outputs and view the responses of the inputs 
Reads from an alias file to attach symbolic names to I/O point definitions on the screen 
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Motion Control Hardware 



The present invention System uses the aforementioned MATR1X4 multi-axis servo controller board. The system's 
approach to motion control maintains digital control throughout the position, velocity, and current loops as part of the 
CNC. As a result, the system achieves more precise, faster, and more robust closed loop control than other servo 
controls. Many control functions are isolated in the motion control software on the host computer This approach give 
the user more flexibility when responding to changing industry needs. This also facilitates retrofitting a new CNC on 
existing machines The MATRIX4 controller board is a fully digital, 4-axis position and velocity controller. The board 
provides constant velocity control as well as spindle orient capability. When coupled with the VECTOR4 daughter 
boa.-d. the system permits the CNC to control DC brush, DC brushless. and AC induction motors and permits most 
oara.-neters to be programmed dynamically. Dynamic programming allows an engineer to update the motion control 
parameters immediately when there are changes in the environment or operating conditions. 



Motion Control Configurations 

45 

Due to the system's configuration flexibility, OEMs can use machines with multiple motors. This is possible because 
the CNC hides the motors from the application software by sending CNC messages through the power modules to 
maneuver the motors. This structure allows easy swapping of motors without drastic changes in the machine design. 
For each controller board, an OEM can configure up to four axes with each axis independently supporting a different 
so type of motor. Four boards can be used together to support up to 16 motors. The power modules between the CNC 
and the motors are inexpensive replacements for the proprietary drives common in many systems today These mod- 
ules can be purchased from many different suppliers. 



Motion Control Software 

ss 

The motion control software in the CNC translates part programming requests into basic position and velocity 
instructions As shown in the illustration on the next page, the motion control software is divided into functional com- 
ponents The operator uses the Part Program Interpreter (PPI) software to direct the motion of the axes. The PPI 
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software may make use of pre-programmed, packaged cycles to perform common operations such as drill and tap. 

The PPI sends requests to Process or Machine Objects. This software loads the requests and manual operations, 
such as tool change or coolant on/off. into shared memory. 

The Interface Driver software has these functions: 

• Extracts and processes requests from shared memory 

• Interpolates motion lines 

• Performs leadscrew mapping 

Sends position/velocity targets to the MATRIX4 board 

The Interface Driver can accommodate simultaneous commands from the host to multiple DSPs. The driver software 
converts requests from the PPI into position and velocity targets that are fed to MATRIX4 through the Motion Interface. 
The driver also uses a 'C 1 library and function prototypes to define commands for the MATRIX4 board. 
The 'C library in the driver software defines the following: 

• Axis designators 

• Module designators 

• Multiple read parameter types 

• Disable interrupts masks 

• Servo modes of operation 

• Axes per module 

• Maximum number of axes per module 

• Output loop gains 

• Control Law indices 

• Control PID gain indices 

• Error codes 

• Maximum and minimum velocities and accelerations 

• Block transfer rate codes 

• Function prototypes 

The motion control software also includes utilities to program the motor technology for the application. These 
utilities permit engineers to configure, tune, and maintain applications as well as document system performance. 

The MATRIX4 board accepts the motion commands and closes the servo control loop. Since axes move by having 
voltages applied to them : the MATRIX4 board converts the position/velocity instructions into voltages (0 to 10 volts) 
and applies the voltages to the axes being controlled. The MATRIX4 board does not need to understand the machine 
tool's operation since that function is handled by the software. 

Machine Configuration Library 

The Machine Configuration Library provides default parameters for applications in a shared memory area This 
service's responsibilities are to - 

• Load and distribute initialization parameters from the file system 
Distribute parameters to applications 

In one embodiment, this parameter library uses a C++ object, SystemVariables, to read and write data in the globally 
accessible shared memory area. The library also contains utilities to create, load the configuration, print, list, save, 
restore, and remove the information in the SystemVariables memory region. 

The information in this section provides the details necessary for an engineer who wants to modify or develop new 
configuration programs. For more general information about these functions, refer to the 'Platform Services' discuss 
herein. 

Defining the Configuration File 

In development work for this platform service, the first step is definition of the configuration file containing the 
system parameters. An ASCII file may be used to define the shared variable name, its size, and each data field in the 
shared memory. For example: 
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# This is an example configuration 

# GT. 11/19/92 

NAME /mnl/mydirectory/sharedfilename 

SIZE 4096 

SOF 
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# NAME 


TYPE 


COUNT 


SIZE 


kTermsX 


INTEGER 


4 




kTermsY 


INTEGER 


4 




kTermsZ 


INTEGER 


4 




kTermsS 


INTEGER 


4 




iTermsX 


INTEGER 


4 




iTermsY 


INTEGER 


4 




iTermsZ 


INTEGER 


4 




iTermsS 


INTEGER 


4 




vTermsX 


INTEGER 


4 




vTermsY 


INTEGER 


4 




vTermsZ 


INTEGER 


4 




vTermsS 


INTEGER 


4 " 




U inn it 


DOUBLE 


4 




max_accel 


DOUBLE 


4 




pwm_freq 


INTEGER 


4 




lines 


INTEGER 


4 




potes 


INTEGER 


4 




hail 


INTEGER 


4 




deadband 


INTEGER 


4 




loopType 


INTEGER 


4 




motorParam 


INTEGER 


4 




field 


INTEGER 


4 




motor 


INTEGER 


4 




TravelLimits 


DOUBLE 


3 




Units 


STRING 


1 


7 



The first two lines for the SystemVariables configuration file are comments beginning with the sign. All keywords 

must be in capital letters in the file. The second line uses the NAME keyword to specify the name of the SystemVariables 
} file. An absolute pain name should be used. The third line specifies the size of the data area using the SIZE keyword. 
' The sae should be specified in 4I< increments, even it the data space used is less than that. The SOF (start o? fields) 

k ywoid must precede the defined fields. 

The six supported field types are byte, string, double, integer, short integer, and long integer. The first column 

identifies the name of the field. Field names are limited to 30 characters plus a null terminator making it a total of 31 
5 characters. The second column defines the field type, string, double and integer. There is no limit to the length of a 

string. The third column defines the number of elements to be stored for that field name. The example shows the field 

'kTermsX* to contain 4 integers. TravelLimits' 3 doubles and 'Units' 1 string containing 7 characters (including any null 

terminator). 

At this time, the SIZE field is used only for the string data type. It indicates the length of the string (including null 
0 terminator). 

Utilities 

After creating a configuration file, the engineer needs to set up the memory area and load the configuration pa- 
5 rameters. The library contains utilities to create the shared memory area, load the configuration, print, list, save, restore, 
and remove the information tn the SystemVariables memory region. These utiliti s are - 
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SVsize 

SVcreate 

SVprint 

SVIoadConfig 

SVIistData 

SVsave 

SVrestore 

SVremove 

SVshmdump 

These utilities are described in the order they are most commonly used beginning with the SVsize utility. 



SVsize 

ts The first utility an engineer may need, SVsize, establishes the size of the shared memory. In the example below 

the 4096 SIZE value provides enough space for the defined shared data area. The Total Bytes Used parameter indicates 
the total amount of space required for the shared data definition that the engineer specified. This figure must be in- 
creased up to the next 4K value and used as the SIZE parameter in the configuration file. 
Sizing 

20 [/mnt/mydirectory/sharedfilename] 

' Size Indicated [4096] 

Header [12] 
Table [1100] 
25 pata [431] 

Total Bytes Used [1543] 
Available Bytes [2553] 
Size Completed. 



30 SVcreate 

After defining the shared data area, the engineer may create the shared data area using the SVcreate utility. Below 
is an example using this utility program. 



35 Building, .[/mnt/mydirectory/sharedfilename] 
Size [4096] 

Shmid[/mnt/mydirectory/sharedfilename] created. 

kTermsX 

kTermsY 
\o kTermsZ 
/ UTermsS 

tfermsX 

iTermsY 

iTermsZ 
^5 iTermsS 

vTermsX 

vTermsY 

vTermsZ 

vTermsS 
so ijimit 

max_accel 

pwm_freq 

lines 

poles 
55 hall 

deadband 

loopType 

motorParam 
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field 
motor 

TravelLimits 
Units 

5 Bytes Used [1543] 

Available Bytes. [2553] 
Build Completed. 

SVpnnt 

w 

Once the shared data area has been created, the engineer may display the data description using the SVprint 
utility. The SVprint utility displays the field name, data type (B, I, D, S. H, L) the count (number of elements) and the 
size of each String field. Below is an example showing integer (I), double (D) and string (S) data types. This utility also 
shows the size of each string field. 

75 

NAME[/mnt/mydirectory/sharedfilename] 
SIZE [4096] 



25 
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) 
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Name 


Type 


uouni 




TravelLimits 


D 


3 


7 


Units 


S 


1 




deadband 


1 


4 




field 




4 




hall 




4 




(Terms S 




4 




iTermsX 




4 




iTermsY 




4 




iTermsZ 




4 




ijimit 


D 


4 




kTermsS 




4 




kTermsX 




4 




kTermsY 




4 




kTermsZ 




4 




lines 




4 




loopTyp 




4 




max_accel 


D 


4 




motor 




4 




motorParam 




4 




poles 




4 




pwm_freq 




4 




vTermsS 




4 




vTemnsX 




4 




vTermsY 




4 




vTermsZ 




4 





50 SVIoadConfiq 

Next the engineer may load default values into the shared memory using the SVIoadConfig utility This utility uses 
an ASCII file describing the values assigned to each field. The format of the file follows: 
# These are the default values used for SharedVariable example programs. 

55 
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Index 


Value 


kTermsX 


0 


7000 


kTermsX 


1 


30000 


kTermsX 


2 


12000 


kTermsX 


3 


19400 


# 






kTermsY 


0 


0 


kTermsY 


1 


20000 


kTermsY 


2 


5000 


kTermsY 


3 


7000 


# 






kTermsZ 


0 


2000 


kTermsZ 


1 


18000 


kTermsZ 


2 


3000 


kTermsZ 


3 


5350 


# 






kTermsS 


0 


7000 


kTermsS 


1 


30000 


kTermsS 


2 


12000 


kTermsS 


3 


19400 


# 






iTermsX 


0 


0 


iTermsX 


1 


15000 


iTermsX 


2 


4000 


iTermsX 


3 


0 


# 






iTermsY 


0 


0 


iTermsY 


i 

i 




iTermsY 


2 


15000 


iTermsY 


3 


0 


# 






Units 


0 


Metric 



In the SVIoadConfig utility, lines beginning with a # sign are interpreted as a comment. The .first column 'P^rtee the 
fl* ,ame while ai > second column is the index. The fields or indexes do not have to be defined ,n any specrf.c orde. 
The itfrd column is the value If a field cannot be found or a value is invalid, an error message « prm.ed. 

SVIistData 

The engineer may list all the data values that are currently stored in the shared area usin g theSVI ^ a ^ ty 
This utility outputs a file that can be read using the SVIoadConfig utility. The value for each field by .ndex « pr.nted. 



SVsave 



After, modifying the data stored in the shared area, an engineer may want to save the information to disk. This can 
be done using the SVsave utility Below is an example using this utility. 



NAME [/mnt/mydirectory/sharedfilename] 

SIZE [4096] 

Save Completed 



The save utility saves 



the shared area under the filename specified in the configuration file with a .sav extension. 
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SVrestore 

To restore a previously saved file, use the SVrestore utility. Below is an example using this utility: 

NAME [/mnt/mydirectory/sharedfilename] 

SIZE [4096] 

Restore Completed 

SVshmdump 

There is another utility, SVshmdump, that may be of interest for debugging the shared area at a very low level. 
This program dumps the shared area in hex bytes and is useful when the engineer wants to inspect the shared area. 

Shared Memory Organization 

The SystemVariables area can be described as a contiguous area of shared memory. This memory is divided into 
three sections: 

Shared Memory Storage Header 
Table of Contents 
Data Storage 

The header is divided into three fields: 

Number of fields defined in the shared area (first 4 bytes) 

Offset into the shared area (used when allocating space for new fields) 

An integer storing the semaphore handle (used to synchronize access to the data area only) 

The header structure is as follows: 



typedef header { 

int. number^ of _f ields ; 

long of f set_irvto_dat.astorage ; 

int semaphore; 

} header ; 

The second four bytes of the header contain a long integer (also fou, bytes) of the offset into the shared ar^ 
This vaiue is used when allocating space for new fields in the shared area. In this scheme the table of contents (the 
field descriptions) grow downward while the data storage area grows upward. Finally, the header 
an integer storing the semaphore handle used to synchronize access to the data area only. This means the semaphore 
is not used when getting information about the fields, but only for reading and writing into the data area. 

Note Te^e sizes described in this document for integer and double reflect those of a 386 and 486 arch.tecture. 
The second section of the shared area is the table of contents. This area contains a series of field descriptions 
each can be described using this data structure: 
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/define FI ELD_NAME_LENGTH 31 
typ def struct f ield_description 
{ 

char fieldname [FIELD_NAME_LENGTH] ; 
char type; 

unsigned int count; 
unsigned int size; 
unsigned int offset; 
} f ield_description ; 

The first 31 bytes of each field description contains the field name. This is the same name that is used in the configuration 
file. At this time an upward limit of 31 characters (including Null terminator) is allowed. The next byte in the description 
indicates the field data type. The six field data types are represented by these letters: 

B-byte 

I - integer 

D - double 

S - string 

H - short integer 

L - long integer 

The next four bytes describe an integer representing the number of elements to be stored under this name. This can 
be considered an index into an array beginning with the index zero for the first element. An integer representing the 
size of each element is stored after the count. Doubles use eight bytes and integers four, with user defined the string 
sizes. The final four bytes of the field description contains the offset from the beginning of the shared area into the data 
storage area where the stored values are kept for the field. 

Writing a Program 

An engineer wishing to write a program to access the shared memory area may want to examine the following 
example. This program simply creates a SystemVariables object, passing the configuration filename to the object. Calls 
are made to the SystemVariables object for getting the size, mapping the fields to field objects, getting and updating 
data, and other necessary actions. 

/include <stream.h>. 
/include "SystemVariables .hpp" 
main (int argc, char *argv[]) 
{ 
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int rror; 
double doubleValue; 

if (argc < 2) 

{ 

cout « form ("Usage: %s conf iguration- 
filename\n", argv[0]) ;exit (-1) ; 

} 

/* Instantiate a SystemVariables object, 
specifying the configuration file name to be used 
*/ 

SystemVariables systemVariables (argv[ 1] , error); 
/* Check the error code returned from the 
constructor call */ 
if (error) 
{ 

perror ("SystemVariables Constructor") ; 
exit (-1) ; 

} 

/* The Size method call is one of many calls 
that will return information about the shared area 
*/ 

if (systemVariables. Size() == 0) 
{ 

perror ("Invalid size") ; 
exit (-1); 

> 

/* 

Here is a simple call to get the value stored in 
the Oth index of the field called "max_accel" . 
*/ 

error = systemVariables . Get ("max_accel" , 
doubleValue, 0) ; 

cout « form ("max_accel value 
[%f ] \n", doubleValue ) ; 
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/* 

Finally, close the connection to the shared 

data area. 

*/ 

if ((error = SystemVariables. Close ( ) ) ) 
{ 

perror ("Cannot close shared area!"); 

} 

} 

Below is the make file used to compile and link this program: 

CFLAGS=-X -I /usr/ local/ include 

OB J= . / 
EXE= . . / 

LIB=/usr/ local/ lib/ 
OFILES= $ (OBJ) example. o 
$ ( EXE) example : $ (OFILES) 

g ++ -x $ (OBJ) example . o $ (LIB) libSV. a-o 

$ (EXE) example 

$ (OBJ) example. o : example. cc 

g ++ - c $(CFLAGS) example. cc -o 

$ (OBJ) example . o 

The SystemVariables methods are described in the following section. 
System Variables Methods 

The Machine Configuration Library uses an object, such as a C ++ object. SystemVariabietv to ,ead and wr*e data 
in the slobby accessible shared memory area. The SystemVariables methods are defined below and the ^.ble 

return values are listed for each method. 

BasePtr 

This class method returns the base pointer to the shared area. The function prototype for this method is - 
char 'BasePtr ( ) 

Return Values: 

A non Null pointer on success. 



Close 



This class method closes a connection to the shared area. The function prototype for this method is - 



int Close ( ) 

Return Values: 
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0 - Success 

-1 - Error. Check 'Ermo' for a description of the error. 

An error may occur during an unmap call of the shared area or a close call to the shared area file. Errno is set when 
these errors occur 

Description 

This class method returns a character string describing the field. The string contains the field name, type, count 
and size (in case of string types). The calling program must perform a delete on the returned description. The application 
may use the Field or GetField method calls to obtain the Field parameter used in this call. The function prototype for 
this method is - 

int Description (svField &fiekJ, char 'description) 
See Also: GetField, Field 

Field 

This method finds the Field for the field specified by fieldName. The function prototype for this method is - 
int Field (char *fieldName, svField &field) 
Return Values: 

0 - Success 

-2 - Cannot find field. 

-3 - Shared Area Not Initialized. See Also: Get, Update. 
FieldCount 

This method gets the number of elements for the field specified by fieldName. The count is returned in the parameter 
count. The function prototype for this method is - 
int FieldCount (char MieldName, int &count) 
Return Values: 

0 - Success 

-2 - Cannot find field. 

-3 - Shared Area Not Initialized. 

FieldSize 

This method gets the size of the field specified by fieldName. The size is returned in the parameter size. The 
'uncfon prototype for -his method is - 

Int FieldSize-- »,c*w ' t; c!dName. int &size) 
Return Values: 

0 - Success 

-2 - Cannot find field. 

-3 - Shared Area Not Initialized. 

FieldType 

This method gets the data type for the field specified by fieldName. The type returned in the parameter type is I 
for integer, D for double, S for string, B for byte, H for short integer, and L for long integer. The function prototype for 
this method is - 

int FieldType (char 'fieldName, char type) 
Return Values: 

0 - Success 

-2 • Cannot find field. 

-3 - Shared Area Not Initialized. 
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FileName 

This class method returns the configuration filename used to define the shared data area. The function prototype 
for this method is - 

char *FileName( ) 

Get 

This method retrieves the value stored for a given field by name. 

int Get (char 'fieldName, int &data. int index) 
int Get (char TieldName, char 'data, int index) 
int Get (char 'fieldName. double &data. int index) 

The index parameter is optional. If it is not used, the 0th index is searched. Care must be taken when getting 
string values. The engineer must make sure the character pointer that is passed into this method has allocated 
enough space to store the character string. A good way to do this is to use the FieldSize method to get the size 
of the character string. Then allocate the space before calling this method. 
Return Values: 

0 - Success, 

•1 - Invalid field type. 

-2 - Field not found. 

-3 - Shared Area Not Initialized. 

-4 - Invalid Index. 

The Get method also retrieves the value stored for a given field as specified by the sfField reference. 

int Get (sfField &field, int &data. int index) 
int Get (sfField &field, char *data, int index) 
int Get (sfField Afield, double &data, int index) 

The Field pointer is found using the Field or GetField methods. The engineer must make sure the character 
pointer that is passed into this method has allocated enough space to store the character string. A good way to 
do this is to use the FieldSize method to get the size of the character string. Then allocate the space before calling 
this method. 

Return Values: 

0 - Success. 

-1 - Invalid field type. 

-3 - Shared Area Not Initialized. 

-4 - Invalid Index 

See A!r,o: Field, GotField, 

FieldSize. 

GetField 

This method call is used to traverse the list of fields in the shared area. By using a zero in the parameter data you 
will begin at the top of the list. After each call the data parameter will be incremented. The list can be traversed by 
calling this method successively until a return value of -l is return. The function prototype for this method is - 
int GetField (svField &field. int &data) 
Return Values: 

0 - Success 
-1 - End of list. 

-3 - Shared Area Not Initialized. 
See Also: Get. Update. 



S7 



EP 0 717 866 B1 



Name 

This class method returns the shared area name specified in the configuration file. The function prototype for this 

method is- 

char 'Name ( ) 

NumberOfFields 

This class method returns the number of fields defined for the System Variables. The function prototype for this 

method is- 

int NumberOfFields( ) 

Remove 

This class method will remove the shared area completely. After this call no other applications will be able to access 
the shared area. The function prototype for this method is- 
int Remove ( ) 

Return Values: 

0 - Success 

-1 - Error occurred during an unmap call or close call to the shared area file. Check errno for a descnption of the error. 

-3 - Shared Area Not Initialized. 

-4 - Cannot unlink the shared area file. 

-5 - Cannot unlink the shared area semaphore. 

Save 

This class method will save a copy of the shared area to disk. The file name will use the shared memory name 
with a suffix of save. The function prototype for this method is- 
int Save ( ) 

Return Values: 

0 - Success 

-1 - Cannot open the save file. 
-3 - Shared Area Not Initialized. 

Refer to the description of the 'Restore* method for more information. 
Restore 

This methoa will restore a saved copy of the shared area. When using the Save and Restore methods a filename 
with the .sav extension is used. The function prototype for this method is- 
Int Pestore( ) 

Return Values: 

0 - Success 

-1 - Cannot open the restore file. 
-3 - Shared Area Not Initialized. 

The Save and Restore methods use the shared area name with a .sav extension appended to it as a filename for 
saving and restoring a shared area. The file is saved in a binary format and can only be read using the Restore 
call. Use the SVIistData utility program to create an ASCII readable file of the current field values. 

Size 

This class method returns the total size in bytes of the shared area (not the amount of shared area being used). 
The function prototype for this method is- 
int Size( ) 
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Update 

The Update method replaces the value stored for a given field with the value given in data. 



5 int Update (char *fietdName t int data, int index) 

int Update (char *fieldName, char *data. int index) 

int Update (char MieldName, double data, int index) 

the index parameter is optional. It it is not specified the Oth index is used. When updating a string field type 

the field size will limit the number of characters stored. For example, if you have a character string of thirty char- 
w acters and you update a field that can only hold twenty, only the first twenty characters will be stored. 

Return Values: 

0 - Success, 
is -1 - Invalid field type. 

-2 - Field not found. 
-3 - Shared Area Not Initialized. 
-4 - Invalid Index 



20 The Update method also replaces the value stored for a given field as specified by the sfField reference. 
) 

int Update (sfField &field. int data, int index) 
int Update (sfField &field, char *data, int index) 
int Update (sfField &field. double data, int index) 

25 

The Field pointer can be found using the Field or GetField methods. 
Return Values: 

0 - Success, 
30 -1 - Invalid field type. 

-3 - Shared Area Not Initialized. 
-4 - Invalid Index 

See Also: Get, Field. GetField. 

35 Semaphore 

This method returns the semaphore handle used to synchronize access to the shared area. The function prototype 
for this method is- 

int Semaphore ( ) 

p o£:t3emaphore 

This method call will release the semaphore used to synchronize access to the shared area. You must use the 
WaitSemaphore method call to get the semaphore before calling this method. The function prototype for this method is - 
45 void PostSemaphore ( ) 

WaitSemaphore 

This method call will get the semaphore used to synchronize access to the shared area. The call will pend until it 
50 can get the semaphore. The function prototype for this method is - 
void WaitSemaphore ( ) 

The WaitSemaphore and PostSemaphore calls are used to allow a program to get access to the shared area and make 
several calls without the overhead of getting and releasing the semaphore with each get/update call. This call should 
be used in conjunction with the PostSemaphore method call. In some cases an application may want to update or get 
55 data for a group of fields without having to get the semaphore for each call. 

In this case the application would make a call to WaitSemaphore, then update/get data for all the fields followed 
by a PostSemaphore call. Care must be taken when performing this call so as not to hold up other processes for too 
long a period. This method will save 35 micros conds from each get/update call. 
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SVfield Methods 

The SystemVariables class uses an SVfield class to describe each field within the SystemVariables. To get a 
reference to individual fields, use the GetField or Field method calls in the SystemVariables class. By getting an SVfield 
reference, the engineer greatly improves the efficiency of accessing fields in the SystemVariables because this elimi- 
nates the search for the individual field. In addition, this provides information about individual fields by making calls to 
the SVfield class methods. This section describes the SVfield class method calls. 

Name 

This class method returns the name of the Field. Field names are currently limited to 31 characters including the 
Null terminator. The function prototype for this method is- 
char 'Name ( ) 



*5 Type 

This class method returns the field data type. The return value may be I (integer), D (double), S (string), B (byte), 
H (short integer), or L (long integer). The function prototype for this method is- 
char Type ( ) 

20 

} Count 

This class method returns the number of elements that may be stored under this field name. Elements are num- 
bered beginning with 0. For example, an integer field with a count of five may be accessed using an index from 0 to 
25 4. The function prototype for this method is- 
int Count ( ) 

Size 



30 This class method returns the size of each field element. Under the Lynx OS (for 386/486 systems) integers and 

doubles are stored in four bytes, strings are stored by any size. For example, a string field with a count of seven and 
a size of ten means there are seven character strings of length ten (including the Null terminator). The function prototype 
for this method is- 
int Size ( ) 



Exception Reporter 

The error codes used to filter error messages are available in the file 'ErrorCodes.hpp.' This file may be modified 
and expanded to meet the customer's needs. 
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/ifndef _ERRORCODESHPP 
#d fine _ERRORCODESHPP 
/ 

§ FileName: ErrorCodes . hpp 
# 

f $Header$ 
# $Log$ 

static char *ERRORCODESHPPRC string = M $Header$ M 

typedef enum ExceptionSeverityValues 
{ 

NO_S EVERIT Y = 0x0000, 
INFORMATION = 0x0001, 
WARNING = 0X0002, 
FATAL = 0X0004, 

A11_SEVERITIES = 0X0007, 
} ExceptionSeverityValues; 

typedef enum Except ionCategoryVa lues 
{ 

NO_CATEGORY = 0x0000, 

MOTION = 0X0001, 
LOGIC_CONTROL = 0x0002, 
DEVICE_LAYET* = 0x0004, 
DIRECTORY SERVICE = 0x0008, 
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RES ERV ED_ 1 0 


0x0010, 


RESERVED_2 0 


0x0020, 


RESERVED_4 0 


0X0040, 


RESERVED_80 


0x0080, 


USER_DEFINED_01 


= 0X0100, 


USER_DEFINED_02 


= 0X0200, 


USER_DEFINED_04 


=0x04 00, 


USER_DEFINED_08 


= 0X0800, 


USER_DEFINED_10 


= 0X1000, 


USER_DEFINED_2 0 


= 0X2000, 


USER_DEFINED_4 0 


= 0X4 000, 


USER_DEFINED_8 0 


= 0X8000, 


ALL CATEGORIES = 


OxFFFF, 



} Except ionCategoryValues ; 



typedef enum ErrorCodes 
{ 



EX_ 


_NO_ERROR, 




EX_ 


_NOT_FOUND, 




EX_ 


_REPLACE_ME_ 


_001, 


EX_ 


_REPLACE_ME_ 


_002, 


EX_ 


_REPLACE_ME_ 


.003, 


EX_ 


_REPLACE_ME_ 


004, 



} 

M'ichil) ? Class 

Creating a New Machine Class 

Creating a completely new Machine Class is a more complex process than simply modifying an existing Machine 
Class. A customer may create a new Machine Class for one of the following reasons: 

* Existing Machine Classes do not contain the objects needed to operate the customer's extremely specialized 
machine 

* The customer wants to replace the messaging interface. 

* The customer has a specialized Kernel and needs to develop a Machine Class to communicate with it. 
As with ail development efforts there are two main stages: preparation and development. 

Preparation 

To prepare for development of a completely new Machine Class, the customer should analyze the target machine 
tool to identify all of its devices. 
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The customer must also identity the system tools to assist in this effort. Some of thesWools are 



* 

OS utilities 
ANSI C compiler 

5 C++ programming features (compiler, inheritance of object characteristics, and isolation o( changes) 

UNIX-based development tools 



The customer needs to become familiar with two important control system components: 



10 * Well-documented Kernel interlace including message parameters and Logic Controller flags (in this manual) 
* Full source code for the sample, generic Machine Class 



An understanding of these two components simplifies the development effort by helping the customer to connect the 
new Machine Class to existing Kernel functions. 

Development Steps 

The steps a developer should follow when creating a new Machine Class are as follows: 

20 1 . After a thorough analysis of the target machine, name all of the devices needed to operate the machine. These 

^) become the new Machine Class objects. 

' 2. Identify all of the methods used by each device. It is often helpful to use the same verbs as those used by 

existing Machine Class objects. In that way, the developer can connect and use the existing messages. 
3. Match the available Kernel functions to the new Machine Class objects. Create new messages where needed. 

25 



Claims 



1. A machine tool control system for a machine tool of the type comprising a controllable, movable tool (22, 23. 24, 
30 25, 26) for shaping a workpiece, means for receiving control instructions describing shaping functions to be per- 
formed on the workpiece, a processing unit (11) and memory means (12, 14), said control system comprising 
means for receiving and storing in memory means (1 2, 14) workpiece shaping instructions; means for transmitting 
(16. 1 7, 1 8) command signals to a movable toot to thereby cause the tool to move; and an object oriented software 
program comprising a plurality of objects, each said object including a plurality of instructions and associated data, 

35 each of said objects carrying out operations with respect to a corresponding concept and exchanging, with other 

said objects, messages indicative of what operation should be carried out or a status of said sending object; char- 
acterized by a software kernel having a motion controller software module for receiving messages from at least 
one of said plurality of objects, the received messages including commands indicating desired movements of a 
movable tool (22, 23 24, 25, 26); and the motion controller software module further comprising means for sending 
•*o command signals to said transmitting means (16, 17. 18) to thereby cause the movable tool (22, 23. 24, 25, 26) 

to move; said software kernel determining said command signais for desired movement of the movable tool in real 
time. 

2. The machine tool of Claim 1 characterized in that at least one of said objects comprises a model of a shaping 
45 process to be performed on a workpiece by the movable tool (22, 23. 24, 25, 26). 

3. The machine tool of Claim 2 characterized in that at least one of the objects comprises a model of a movable tool 
for shaping a workpiece, and the movable tool object exchanges messages with the shaping process object. 

so 4. The" machine tool of Claim 1 characterized by first and second objects each comprising a model of a shaping 
process to be performed on a workpiece. and the model of the second object is inherited from the first object. 

5. The machine tool of Claim 1 characterized in that at least one of said objects comprises a model of a hole-making 
process capable of forming a hole in a workpiece. the model including definitions of the X. Y and Z dimensions of 

55 the hole. 

6. The machine tool of Claim 1 characterized in that at least on of said obj cts comprises a model of a milling process 
capable of being formed in a workpiece, the model including a two-dimensional definition of a shape. 
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7. The machine tool of Claim 1 characterized in that at least one of said objects comprises a model of a contouring 
process capable of being performed on a workpiece being turned in a lathe. 

8. The machine tool of Claim 1 characterized in that the objects include status means r presentative of whether the 

5 process defined by the object has been performed on a workpiece. 5 

9. The machine tool of Claim 1 characterized in that at least one of the objects comprises a model of a movable tool 
for use in connection with shaping a workpiece. 

10 1 0. The machine tool of Claim 1 characterized by means for receiving from movable tools signals indicating faults with io 
a movable tool (22, 23, 24, 25, 26), and a device fault software module comprising means for storing information 
regarding detected faults from movable tools, means for storing, for each detected fault, a sublist of the objects to 
which to send an object oriented message identifying the detected fault, and means for sending, upon receiving 
information regarding a movable tool fault, an object oriented message to each object associated with the fault. 



15 



1 1 . The machine tool control system of claim 1 characterised in that one of said objects includes a movable tool data 
dictionary storage with parameters for a movable tool and methods for accessing said parameters, said parameters 
including at least one of the parameters of kinematics, servo tuning, safety regions, maximum feed rates, maximum 
acceleration, maximum RPM for the spindle, lead screw mapping, travel limits and feed forward gains for each 
20^ axis, remote communications, and language. 20 

9 12. The machine tool control system of claim 1 characterised in that said objects are arranged in a plurality of layers, 
and said message means directs messages through said layers according to application qualifiers relating to said 
messages, each said layer providing predetermined message sequencing according to how each qualifier relates 
25 to a task. 25 



Pat ntanspruche 

30 1. Werkzeugmaschinen-Steuersystem fur eine Werkzeugmaschine des Typs, die ein steuerbares Bewegtwerkzeug 
(22, 23, 24, 25, 26) zur formgebenden Bearbeitung eines Werkstucks, eine Einrichtung zum Empfangen von Steu- 
eranweisungen, die Formgebungsfunktionen beschreiben, die an dem Werkstuck auszufuhren sind, eine Verar- 
beitungseinheit (11) und Speichereinrichtungen (12, 14) aufweist, wobei das Steuersystem folgendes aufweist: 
eine Einrichtung, urn Werkstuck-Formgebungsbefehle zu empfangen und sie in Speichereinheiten (12, 14) zu 

35 speichern; eine Einrichtung zum Ubertragen (16, 17, 18) von Befehlssignalen an ein Bewegtwerkzeug, urn das 

Werkzeug zu einer Bewegung zu veranlassen; und ein objektorientiertes Softwareprogramm, das eine Vielzahl 
von Objekten aufweist, wobei jedes Objekt eine Vielzahl von Anweisungen und zugehorigen Daten umfaGt und 
jedes dieser Objekte Operationen in bezug auf ein entsprechendes Konzept ausfuhrt und mit anderen der Objekte 
Nachrichten austauscht, die bezeichnen, welche Operation durchgefuhrt werden sollte. oder einen Status des 

- ^ sendonden Objekts bezeichnen; gekennzeichnet durch einen Sotftwarekern, der ein Bewegungssteuergerat-Soft- 
J warefnodu! ha*, um Nachrichten vor wenigstens einem der Vielzahl von Objekten zu empfangen, wobc-i oie emp- 

fangenen Nachrichten Befehle aufweisen, die Sollbewegungen eines Bewegtwerkzeugs (22, 23, 24, 25. 26} be- 
zeichnen; und wobei das Bewegungssteuergerat-Sofiwarcmodul femer eine Einrichtung aufweist, um Befehlssi- 
gnale an die Obertragungseinrichtung (16, 17, 18) zu senden, so da3 das Bewegtwerkzeug (22. 23, 24. 25, 26) 

<*5 zu einer Bewegung veranlaBt wird; wobei der Softwarekern die Befehlssignate fur eine Sollbewegung des Bewegt- 

werkzeugs in Echtzeit bestimmt. 

2. Werkzeugmaschine nach Anspruch 1, dadurch gekennzeichnet, da(3 wenigstens eines der Objekte ein Model! 
eines Formgebungsvorgangs aufweist, der von dem Bewegtwerkzeug (22, 23, 24, 25, 26) an einem Werkstuck 

so auszufuhren ist. 

3. Werkzeugmaschine nach Anspruch 2. dadurch gekennzeichnet, daG wenigstens eines der Objekte ein Modell 
eines Bewegtwerkzeugs zur formgebenden Bearbeitung eines Werkstucks aufweist und das Bewegtwerkzeugob- 
jekt Nachrichten mit dem Formgebungsvorgangobjekt austauscht. 

55 

4. Werkzeugmaschine nach Anspruch 1, gekennzeichnet durch ein erstes und ein zweites Objekt, die jeweils ein 
Modell eines an einem Werkstuck auszuf uhrenden Formgebungsvorgangs aufweisen. wobei das Modell des zwei- 
ten Objekts von dem ersten Objekt vererbt ist. 
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5. Werkzeugmaschine nach AnsproSTl. dadurch gekennzeichnet. daB wenigsterr^fnes der Objekte ein Modell 

eines Lochherformungsvorgangs aufweist, der imstande ist, ein Loch in einem Werkstuck zu formen, wobei das 
Modell Definitionen der X-. Y- und Z-Dimensionen des Lochs aufweist. 

6. Werkzeugmaschine nach Anspruch 1. dadurch gekennzeichnet. daB wenigstens eines der Objekte ein Modell 
eines Frasvorgangs ist. der in einem Werkstuck ausgefuhrt werden kann, wobei das Modell eine zweidimensionale 
Definition einer Form aufweist. 

7. Werkzeugmaschine nach Anspruch 1, dadurch gekennzeichnet, daB wenigstens eines der Objekte ein Modell 
eines Konturiervorgangs ist, der an einem Werkstuck ausgefuhrt werden kann, das in einer Drehmaschine gedreht 
wird. 

8. Werkzeugmaschine nach Anspruch 1, dadurch gekennzeichnet, daB die Objekte Statuseinrichtungen aufweisen, 
die daf ur reprasentativ sind, ob der durch das Objekt definierte Vorgang an einem Werkstuck ausgefuhrt worden ist. 

9. Werkzeugmaschine nach Anspruch 1, dadurch gekennzeichnet, daG wenigstens eines der Objekte ein Modell 
eines Bewegtwerkzeugs aufweist, das in Verbindung mit der formgebenden Bearbeitung eines Werkstucks an- 
wendbar ist. 

10. Werkzeugmaschine nach Anspruch 1, gekennzeichnet durch eine Einrichtung, die von Bewegtwerkzeugen Signale 
empfangt, die Fehlermit einem Bewegtwerkzeug (22, 23, 24, 25, 26) bezeichnen, und wobei ein Vorrichtungsfehler- 
Softwaremodul folgendes aufweist: Mittel zum Speichern von Informationen in bezug auf detektierte Fehler von 
Bewegtwerkzeugen, Mittel, um fur jeden detektierten Fehler eine Unterliste der Objekte zu speichern, an die eine 
objektorientierte Nachricht zu senden ist, die den detektierten Fehler identifiziert, und Mittel, um bei Empfang von 
Informationen in bezug auf einen Fehler eines Bewegtwerkzeugs eine objektorientierte Nachricht an jedes Objekt 
zu senden, das mit dem Fehler in Beziehung steht. 

11. Werkzeugmaschinen-Steuersystem nach Anspruch 1, dadurch gekennzeichnet, daB eines der Objekte einen Be- 
wegtwerkzeugdaten-Dateilistenspeicher mit Parametern fur ein Bewegtwerkzeug und Methoden zum Zugriff auf 
diese Parameter autweist, wobei die Parameter wenigstens einen von den Parametern Kinematik, Servoabstim- 
mung, Sicherheitszonen, Hochstvorschubraten, Hochstbeschleunigung, Hdchstdrehzahl f Or die Spindel, Leitspin- 
del-Mapping, Streckenbegrenzungen und Vorschubzunahme lur jede Achse, Telekommunikation und Sprache 
aufweisen. 

12. Werkzeugmaschinen-Steuersystem nach Anspruch 1, dadurch gekennzeichnet, daB die Objekte in einer Vielzahl 
von Ebenen angeordnet sind und daB die Nachrichteneinrichtung Nachrichten durch diese Ebenen in Abhangigkeit 
von Anwendungskennzeichnern, die auf diese Nachrichten bezogen sind. leitet, wobei jede Ebene eine vorbe- 
stimmte Nachrichten-Sequentialisierung in Abhangigkeit davon. wie jeder Kennzeichner sich auf eine Aufgabe 
bezieht, ermdglicht. 



Revendicattons 

1 . Systeme de commande de machine-outil destine a une machine-outil du type qui comporte un outil reglable mobile 
(22. 23, 24, 25. 26) destine a donner sa forme a une piece, un dispositif de reception d'instructions de commande 
decrivant des fonctions de mise en forme a executer sur la piece, une unite (11) de traitement et un dispositif a 
memoire (12. 14), le systeme de commande comprenant un dispositif destine a recevoir et conserver dans le 
dispositif a memoire (12, 14) des instructions de mise en forme de piece, un dispositif (16. 17, 18) de transmission 
de signaux de commande a un outil mobile afin que I'outil se deplace, et un programme sous forme d'un logiciel 
oriente objet comprenant plusieurs objets. chacun des objets comprenant plusieurs instructions et des donnees 
associees. chacun des objets executant des operations relatives a un concept correspondant et echangeant, avec 
d'autres objets. des messages reprdsentatifs de Toperation qui doit etre executee ou d'un etat de I'objet emetteur, 
caracterise par un noyau logiciel ayant un module logiciel d'organe de commande de mouvement destine a recevoir 
des messages d'au moins Tun des objets. les messages recus comprenant des commandes indiquant des mou- 
vements voulus d'un outil mobile (22. 23. 24. 25. 26). et le module logiciel d'organe de commande de mouvement 
comprenant en outre un dispositif destine a emettre des signaux de commande vers le dispositif de transmission 
(16. 17. 18) afin qu'il provoque ainsi le deplacement de I'outil mobile (22, 23. 24. 25. 26). le noyau logiciel d6ter- 
minant les signaux de commande pour le deplacement voulu de I'outil mobile en temps reel. 
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2. Machine-outil selon la revendication 1. caract6ris6e en ce que Tun au moins des objets est un module d'une 
operation de mise en forme k executer sur une piece par Poutil mobile (22. 23, 24, 25, 26). 

3. Machine-outil selon la revendication 2. caracterisee en ce que Tun au moins des objets st un modele d'un outil 
mobile destine k la mise en forme d'une piece, et I'objet outil mobile echange des messages avec I'objet processus 
de mise en forme. 

4. Machine-outil selon la revendication i. caracterisee par des premier et second objets comprenant chacun un 
module d'un processus de mise en forme a executer sur une piece, et le module du second objet est herite du 
premier objet. 

5. Machine-outil selon la revendication 1, caracterisee en ce que Tun au moins des objets est un module d'un pro- 
. cessus d'usinage d'un trou capable de former un trou dans une piece, le modele comprenant des definitions des 

dimensions X. Y et 2 du trou. 

6. Machine-outil selon la revendication 1, caracterisee en ce que I'un au moins des objets est un modele d'un pro- 
cessus de f raisage qui peut etre forme sur une piece, le modele comprenant une definition bidimensionnelle d'une 
configuration. 

7. Machine-outil selon la revendication 1, caracterisee en ce que I'un au moins des objets est un module d'un pro- 
cessus de formation d'un profil qui peut etre execute sur une pi6.ce par tournage au tour. 

8. Machine-outil selon la revendication 1, caracterisee en ce que les objets comprennent un dispositif d'etat repre- 
sentatif du fait que le processus defini par I'objet a ete execute sur une piece. 

9. Machine-outil selon la revendication i, caracterisee en ce que I'un des objets est un modele d'un outil mobile 
destine a etre utilise avec la mise en forme d'une piece. 

10. Machine-outil selon la revendication 1, caracterisee par un dispositif de reception, k partir d'outils mobiles, de 
signaux indiquant des defauts d'outil mobile (22, 23, 24, 25, 26), et un module logiciel de defaut de dispositif 
comprenant un dispositif destine a memoriser des informations relatives a des defauts choisis des outils mobiles, 
un dispositif de memorisation, pour chaque defaut detecte, une sous-liste des objets auxquels est transmis un 
message oriente objet identifiant le defaut detecte, et un dispositif destine k transmettre, apres reception d'infor- 
mations relatives a un defaut d'outil mobile, un message oriente objet a chaque objet associe au defaut. 

1 1 . Systeme de commande de machine-outil selon la revendication 1 , caracterise en ce que I'un des objets comprenant 
une memoire de dictionnaire de donnees d'outil mobile avec des parametres d'un outil mobile et des methodes 
d'acces aux parametres, les parametres comprenant au moins I'un des parametres de comportement cinematique, 
d'accord d'asservissement, de regions de securite, de Vitesse maximale d'avance, d'acceleration maximale, de 
vitesse maxfmale de rotation de la broche, de mappage de vis-rrere. de limites tie deplacement et de gain d'avance 
poor cheque axe, de communications a distance et de langage. 

12. Systeme de commande de machine-outil selon la revendication 1 , caracterise en ce que les objets sont disposes 
en plusieurs couches, et le dispositif k messages dirige des messages dans les couches en fonction de descripteurs 
d'application relatifs aux messages, chaque couche donnant une sequence predetermin^e de messages en fonc- 
tion de la maniere dont chaque descripteur est lie a une tache. 
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